Changelog RRF 3.x

RepRapFirmware 3.5.3

Upgrade notes:

[Duet 3 Mini 5+] [Duet 3 EXP3HC] [Duet 3 TOOL1RR] The accuracy of reading thermistors and PT100 sensors has been improved. To get the best accuracy, the inputs should be recalibrated.

New features:

The four values reported by M558.1 are now labelled (issue 999)
A simulation can now be resumed when the Duet has 5V power but not VIN power
[Duet 3 MB6HC] [Duet 3 MB6XD] When using DotStar LED strips the colour order of the strip can now be configured (M950 K parameter)
[Duet 3 MB6XD] Version 1.02 of main board 6XD is recognised
[Duet 3 MB6HC] Version 1.02b of main board 6HC is recognised
[Duet 3 EXP1HCL] Pin names spi.cs0 and spi.cs1 are now available (cs1 is only present on board version 2.0)
[Duet 3 TOOL1LC] A little more free RAM is available
OEM board F3PTB is supported

Bug fixes:

It was not possible to create a local variable with the same name as a parameter (issue 1003)
[Duet 3] Motor idle current percent was not implemented on main boards used as expansion boards (issue 1019)
The # operator returned the wrong result when its operand was an array of arrays (issue 1020)
A spurious parsing error was reported under some conditions when parsing a ternary expression (issue 1021)
In SBC mode if a GCode command expected an integer parameter but a string parameter was supplied, the value defaulted to 0 instead of reporting an error (issue 1022)
M17 did not energise the motor brake solenoid (issue 1023)
A reset could occur if MQTT was used when the WILL message had not been set
The machine state was set to Cancelling while stop.g was being run at the end of a print (issue 1024)
Under some conditions a reset occurred when creating a variable from an object model array (issue 1029)
Resuming a simulation was not possible when only 5V power was supplied to the main board
In M569.2 is was not possible to write values of 2^31 or greater because they were converted to floating point
G17/18/19 and G68/69 were not processed in simulation mode. This could give rise to spurious error messages on G2/G3 commands.
If M584 with the R1 parameter was used to create a linear axis using an axis letter defaulted to rotational then in feed rate calculations it was treated as a rotational axis unless parameter S0 was also present (issue 1043)
Assigning an indexed part of an an object model to a variable didn't work and provoked an error message (issue 1029)
It was not possible to use positive numeric literals greater than 2^31-1 in expressions. This was a particular problem when constructing hex value to write to stepper driver registers. Values up to 2^32-1 are now supported.
When M552 S0 was used to disable a network interface, if the specified interface was in the middle of the transaction at the time then very occasionally this would result in a Hard Fault reset. Similarly if M586 was used to disable a network protocol while a transaction using that protocol was active.
[Duet 3] If M569.7 was used to configure a brake on a main board used as an expansion board, the command returned "Error: M569.7" even though there was no error (issue 1039)
[Duet 3 TOOL1LC] The colours of WS2812 (Neopixel) LEDs connected to the tool board were not set correctly
[Duet 3 scanning Z probe] The bootloader could not be updated over CAN
[Duet 3 main boards] The green ACT LED is no longer triggered when a normal filament monitor status message is received
[Duet 3 + SBC] a race condition occasionally caused the file pointer to be corrupted after running a macro, typically resulting an an error message because the file pointer did not point to the start of a line

RepRapFirmware 3.5.2

Upgrade notes:

The M38 command (compute SHA1 hash of file on SD card) is no longer supported. This has been done to make room in flash memory for bug fixes on Duet 2. SHA1 is no longer considered secure and RRF uses a CRC32 to verify that no errors are introduced when uploading files.
The P parameter of M115 is no longer supported. In RRF3 it was only supported on Duet 2 and its use was undocumented.

Feature improvements:

When an array parameter of a GCode command has too many elements, in the "array too long" message RRF now reports the parameter letter instead of the maximum number of elements accepted (issue 907).
Main board firmware now handles new event types "overvoltage" and "undervoltage" that may be generated by expansion boards in future.
The type of automatic status response sent to USB and/or AUX ports while waiting for something to happen (e.g. heating) no longer depends on the emulation mode, it now depends only on the type of status response (M105, M408 S0 or M409) last requested on that input.
Increased maximum number of bytes in a M261 or M262 I2C transaction from 32 to 34.
[Duet 3 MB6HC] [Duet 3 MB6XD] The maximum number of extruders per tool supported on these boards has been increased from 10 to 12.
[Duet 3 MB6XD] Port PD24 now has an ATE pin name so that it can be tested.
[Duet 3] Expansion and tool boards, and main boards used as expansion boards, recognise the new CAN message to define input shaping used by RRF 3.6.0-alpha1, thereby avoiding CAN timeouts when used with a main board running 3.6.0-alpha1.

Bug fixes:

When G10 was the configured retract hop was executed even if the Z axis was not homed or the hop would exceed the configured Z axis limit (issue 967)
After sending M112 it was possible to reactivate a spindle. Now the only commands permitted after M112 are M105 M112 M115 M122 M408 M409 and M999. (issue 992)
If the acceleration was set very high or the commanded speed of a move was very low, so that the acceleration or deceleration took a very short amount of time, movement would cease (issue 994 and issue 989). This was a new bug in RRF 3.5.0.
Soft machine axis limits on Linear Delta, SCARA and other nonlinear kinematics were not respected for moves that did not specify X and Y and Z coordinates (issue 997). This was a new bug in RRF 3.5.0.
[Duet 3 Mini WiFi] [Duet 3 MB6HC + WiFi module] It was not possible to configure MQTT support in config.g. (issue 1001)
The mechanism for extruder step generation to account for partial extrusion steps in a move was inaccurate. This could impact print quality, especially when using short move segments (e.g. during G2 and G3 moves) and extruders with very low steps/mm. (issue 1006)
The total reported CPU usage in the Tasks section of the M122 report would exceed 100% if the machine has been running for longer than about 45 minutes. (issue 1005)
Assigning values to elements of arrays within arrays using the 'set' command sometimes led to unpredictable behaviour (issue 1008)
The number of consecutive array indices permitted in an expression was 4 in some contexts and 5 in others. Now it is 5 consistently.
When an attached Single Board Computer was used the permitted depth of expression nesting was very low (issue 1012
When an extrusion-only move was followed by a Z-only move, jerk was incorrectly applied to the start of the Z move (issue 990)
If a macro file used the M98 R1 command to indicate that it could be paused and restarted, then when the macro was executed from a job file and then paused, the job was restarted from the beginning instead of from the line that called the macro (issue 1004). This was a new bug in RRF 3.5.0.
[Duet 2] When the object model became very large due to e.g. a large number of axes and/or tools being configured, and a PanelDue was part of the system, Duet Web Control would disconnect frequently (issue 995)
[Duet 3] Simple switch type filament monitors that are connected to a main board but assigned to an extruder on a tool or expansion board now work
[Duet 3 MB6HC] [Duet 3 MB6XD] When a Neopixel LED strip was configured on a part other than the LED port, the first LED in the strip sometimes had the wrong colour (issue 996). This was a new bug in RRF 3.5.0.
[Duet 2 + SBC] Using M37 to simulate a job file didn't work, it ran the job instead.
[Duet + SBC + PanelDue] Spurious stack underflow messages were generated
[Duet + SBC] In SBC mode the "network" and "volumes" parts of the object model available on the Duet did not correspond to the values managed by the SBC

RepRapFirmware 3.5.1 stable (changes since 3.4.6)

Breaking changes and other important upgrade notes:

Previously, when resuming after a power failure, prior to invoking resurrect-prologue.g the resurrect.g file used a G92 command to set all axis positions to the machine positions that the axes had when the power failure occurred. This didn't work when using multiple motion systems, and if a tool was selected at the time then the tool offsets were not taken into account. RRF no longer writes the G92 command to resurrect.g, instead it passes the machine coordinates of the axis positions as parameters X, Y, Z... to resurrect-prologue.g. Therefore, if you were previously relying on the G92 command to set axis positions you must execute a suitable G92 command in resurrect-prologue.g. For example, if you can't home Z when there is a print on the bed then you can use command G92 Z{param.Z} in resurrect-prologue.g (note, if you have a tool selected at this time then you will need to subtract the tool Z offset).
If you have more than one probe configured using M558, and you rely on files deployprobe.g and retractprobe.g being called only for probe 0, then you must rename them to deployprobe0.g and retractprobe0.g. See below.
The meaning of the M593 L parameter has changed. Previously it was the minimum value to which acceleration might be reduced in order to apply input shaping. Now it is the minimum fraction of the original acceleration or feed rate to which the acceleration or feed rate may be reduced in order to apply input shaping. The default is 0.25 and the acceptable range is 0.01 to 1.0.
M98 now requires the P parameter to be a quoted string. Previously, in standalone mode an unquoted string was permitted. If M98 is used as the action in a 12864 display menu, enclose the filename after M98 P in two pairs of double quotes, because the entire action string is already enclosed in double quotes.
Previously in an M98 or G29 or G32 command it was possible to pass parameters whose values were expressions that normally need to be enclosed in { } for example M98 P"myMacro.g" Strue and to create null parameters using M98 P"myMacro.g" S. This is no longer permitted and will give rise to an error message. Use e.g. M98 P"myMacro.g" S{true} and M98 P"myMacro.g" S{null}.
LED strips must now be created using M950 with E parameter. M150 commands can specify the strip number using the new E parameter. M150 X and Q parameters are no longer supported.
M116 without parameters only waits for slow heaters (beds, chambers) and for the selected tool heaters of the current tool (if any) assigned to the current motion system. In previous versions, M116 waited for all heaters to reach their target temperatures
The following object model fields have been removed (they have been flagged 'obsolete' since version 3.3) so you must change anywhere them in config.g, other macro files, slicer start GCode etc.:
- sensors[].probes[].speed (use sensors[].probes[].speeds[1] instead)
- sensors[].probes[].temperatureCoefficient (use sensors[].probes[].temperatureCoefficients[0] instead)
- move.compensation.probeGrid.{axis0, axis1, xMin, yMin, xMax, yMax, xSpacing, ySpacing} (use axes[], mins[], maxs[], spacings[] instead)
- move.workspaceNumber (use move.workplaceNumber)
- directories.scans
If the min or max function was called with a single operand, in previous versions that operand was always returned regardless of its type. Calling min or max with a single operand is now allowed only if the operand is a non-empty array of numeric values, and it returns the minimum or maximum element in the array.
Previously, where a GCode command has a parameter that accepts multiple values separated by colon, it was acceptable for each individual value to be an expression enclosed in { }. This is no longer accepted, however the entire parameter can now be an array expression enclosed in { }. For example, if you were using M92 E{global.e0StepsPerMm}:400 you must replace this by M92 E{global.e0StepsPerMm, 400}.
Previously, unless M564 was used to ignore machine limits, all axis limits were enforced on all G0 and G1 moves. This sometimes caused a problem on the next move if an axis limit was changed when the axis coordinate was outside the new limit. Axis limits are now enforced only for those axes that were mentioned in the G0 or G1 move.
The default maximum accelerations were very conservative by modern standards so they have been increased. Likewise the default maximum Z speed has been increased and the default Z steps/mm has been reduced. These changes will only affect you if you do not define the maximum speeds, accelerations and steps/mm for all axes using M201, M203 and M92.
Default M201.1 values (accelerations for stall homing and Z probing moves) are now set. If you do not use the M201.1 command to change these values then acceleration during bed probing and stall homing moves may be lower than before.
M667 is no longer supported. To select CoreXY mode use M669 K1 instead.
The use of M1 to end a job is deprecated. The M1 command no longer runs file sleep.g, instead it runs stop.g like M0. In future we expect to change the behaviour of M1 to be in line with the NIST standard.
It is no longer acceptable to use the G1 S parameter instead of the H parameter to indicate a homing move or other special move. In previous versions the S parameter was accepted when not in laser mode but a warning message was generated.
When a print is cancelled, cancel.g is run regardless of whether all axes are flagged as having been homed. You may need to modify your cancel.g file to check whether axes have been homed before trying to move them.
The error descriptions in heater fault event messages and in the response when M308 is used to query a sensor have been replaced by shorter error codes, e.g. "short-circuit in sensor" has been replaced by "shortCircuit" and "success" has been replaced by "ok". These error descriptions are now the same as in new object model value sensors.analog[].state.
For WiFi-equipped main boards, the recommended WiFi module firmware version is 2.1.0
In some previous firmware versions, M500 would sometimes write commands with duplicate parameters to the config-override.g file. Such commands may now provoke error messages when config-override.g is processed, in particular when in SBC mode. To fix this, run M500 again.
[Duet 2] The standard Duet 2 build no longer supports Hangprinter, Rotary Delta or 5-bar SCARA kinematics. It should still be possible to compile a binary that support one of these kinematics, but you will have to disable another kinematics (e.g. ordinary SCARA or linear delta) to free up enough space in flash memory.
[Duet 2] Scanner support has been removed. It was only enabled in the Duet 2 build and as far as we know, it was no longer used.
[Duet 2] Rotary delta kinematics is no longer supported. This change has been made to free up flash memory space for new features.
[Duet 3 MB6HC] [EXP3HC] [EXP1HCL] If you were using the T parameter of the M915 command, this value was incorrectly being written to the stall sensitivity register in previous releases. It is now written to the correct register (COOLCONF).
[Duet 3 EXP1HCL] The M569.1 configuration parameters have changed. For quadrature encoders, the C parameter is now the number of quadrature pulses per revolution. The new S parameter is the number of full steps per revolution, default 200.
[Duet 3 EXP1HCL] Default warning and error thresholds are now set for generating events when the driver fails to maintain position

Feature improvements and changed behaviour:

Multiple motion systems are supported on all Duet 3 series main boards. See https://docs.duet3d.com/en/User_manual/RepRapFirmware/Multiple_motion_systems.
Array-valued user variables are now supported
Input shaping is now supported on axes driven by CAN-connected expansion boards
WiFi-enabled boards now support some WPA2-Enterprise experimentally using WiFi module firmware 2.1.0. Duet 2 and Duet 3 Mini boards support modes EAP_PEAP_MSCHAPV2 and EAP_TTLS_MSCHAPV2. Duet 3 MB6HC with the optional WiFi module supports those modes and also EAP_TLS.
G17/18/19 no longer wait for motion to stop if the plane being selected is the same as the current one
G69 command now waits for all motion to stop before being executed
G73 (inverse time mode) and G74 (normal feed rate mode) commands are now supported experimentally
M0 no longer sets drivers to idle current immediately
M2 (end job) command is now supported. It behaves the same as M0.
M3 M4 and M5 commands are now supported in FDM mode (previously they were supported in CNC mode and M3 was supported in laser mode)
M17 (enable drivers) command now waits for all motion to stop before being executed
M18 (disable drivers) command now activates (i.e. removes power to) any associated motor brake(s) by 200ms before turning the motor(s) off. We intend to make this time configurable in future.
M22 now checks whether there are any open files on the SD card and doesn't unmount it if there are
M36 when it returns an error response now includes the filename concerned in that response
M81 command now supports the new D (delay) parameter
M98 now always requires the P parameter to be a quoted string. Previously, in standalone mode an unquoted string was permitted, but using an unquoted string resulted in spurious null parameters being passed to the macro.
M111 B parameter has been added
M122 now includes the connected channel number in the WiFi section when running version 2.x WiFi firmware
M122 report now includes input shaping statistics
M122 reports improved CAN diagnostics
M150 with parameter F1 no longer waits for motion to stop when using a bit-banged port
M200 command now supports the new S parameter so that volumetric extrusion can now be enabled/disabled without changing the filament diameter, and vice versa
M291 command now supports new message box modes 4, 5, 6 and 7. These are supported by DWC but not yet by PanelDue.
M291 messages are now queued. When a M291 command is executed the new message is added to the end of the queue, and any non-blocking messages already in the queue have their timeouts reduced to 1 second. If the queue is already full then the oldest non-blocking message is cancelled, or if there are no non-blocking messages in the queue, the oldest message is cancelled. The queue length is currently 8 messages.
M303 command now has an optional Q (Quiet) parameter to suppress the suggestions to edit config.g or run M500 when it finishes. Use this if you run M303 inside a macro that saves the new parameters automatically.
M308 command now has optional additional U and V parameters to facilitate temperature correction
M425 backlash compensation is supported experimentally
M472 (delete file or folder, optionally recursively) has been added
M500 P10 now saves the tool offsets to 3 decimal places instead of 2
M558 now supports two dive heights. When probing multiple times at the same point, the second and subsequent probes use the second dive height and it is calculated relative to the height at which the probe last triggered. The idea is to speed up probing if you make the second dive height smaller than the first.
M558 supports new Z probe type 11 (scanning analog probe), however implementation is incomplete and dummy data is recorded
M569.7 now supports S parameter to specify the delay between engaging the brake and disabling the driver
M570 command supports a new R parameter, which is the maximum number of consecutive bad temperature readings allowed before a heater fault is triggered
M574 with no parameters no longer waits for movement to stop before reporting on the endstops
M582 command can now set triggers pending unconditionally using the new S parameter
M587.2 report in JSON format: the rssi value is now reported as an integer instead of a string
M587.2 report now includes the channel number and MAC address of each access point found
M591 when used with magnetic filament monitors now reports "firmware version #" instead of "v#"
M593 L parameter has a new meaning, see the Upgrade Notes
M599 with any axis parameters now removes all unmentioned axes from the keepout zone definition
M950 F command now has optional additional K parameter to set the tacho pulses per revolution
Filament monitor calibration data is reset when a magnetic or laser filament monitor is disabled and then enabled.
Maximum stored length of a build object name had been increased from 50 to 100 characters
The resurrect.g file now handles multiple motion systems at least partially
The resurrect.g file now restores the mix ratio if a mixing extruder is in use
The resurrect.g file now restores the cold extrusion allowed/not-allowed state
The resurrect.g file now restored the M204 acceleration settings
When heater model parameters are validated, parameters are no longer rejected just because the estimated maximum temperature rise is too high
When heater model parameter validation fails the "bad model parameters" message now includes the reason
The Z axis can now be mapped on a per-tool basis with M563 (previously only X and Y could be mapped)
When RRF needs to deploy a Z probe, it first tries to run deployprobe#.g where # is the probe number. If that file is not found then it used to be the case the for probe only it tries to run deployprobe.g. Now, if deployprobe#.g is not found it tries to run deployprobe.g regardless of the probe number and it passes the probe number as the K parameter. This makes it possible to use a single deployprobe.g file to handle all probes. Similarly for retractprobe.g.
Live filament monitor data is now available in the object model
Live statistics from Duet3D closed loop drivers are now available in the object model
Improved diagnostics for filament monitors
The limit on block nesting is increased to 65535 (was previously 10)
Main board firmware RAM usage has been reduced by about 1.5kbytes
Filament monitors can now be activated even when not printing from SD card, by using S2 in the M591 command instead of S1; but in this case a filament-error event macro must be defined because the default action (pause the print) won't work unless printing from SD card
The maximum number of elements permitted in a literal array has been increased from 10 to 40
Character literals are now available in meta-GCode expressions
A new function fileread() is supported in GCode expressions
Input shaping is now applied to a wider range of move types, in particular to short accelerate/decelerate moves
In SBC mode the M291 P1 command didn't work correctly
Scanning Z probes using the LDC1612 chip are supported experimentally, on modified tool boards and on SAMMYC21 boards
Use of mesh bed compensation no longer caused moves to be segmented when the Z height is above the compensation taper height
Error messages resulting from GCode command lines now include the column number (if available) even if the command was not read from a file
Up to 5 LED strips can now be configured on most main boards (see Upgrade Notes)
Expansion boards and main boards used as expansion boards can support LED strips
Expression parser now supports ceil(x) function
pow(x, x) now returns an integer if a is an integer, b is a non-negative integer and the result fits in an integer
The timeout before resetting the processor if the heater control task fails to run has been reduced from 20 to 4 seconds
HTTP session keys are now supported in standalone mode to support multiple sessions from a single IP address. See the amended rr_connect docs for further information
Reinstated implicit repetition of a previous G2/G3 command in CNC and laser mode when the line doesn't start with G, M or T and the first letter is instead an axis name
Driver stall events on main boards are no longer disabled when not printing from SD card
The minimum arc segment length has been reduced from 0.1mm to 0.02mm
Fans can now be un-configured by using M950 F# C"nil" where # is the fan number
When input shaping is used, extruder motion is now synchronised to the shaped axis motion
HTTP API call rr_delete now takes an optional "recursive=yes" parameter
The FTP server now supports the optional directory parameter in the LIST command
When an unexpected software reset occurs the floating point registers are now omitted from the stack trace, which makes it more useful
When a "stuck in spin loop" or "heat task stuck" software reset occurs the stack of the stuck task is recorded instead of the stack of the currently-executing task
In laser mode a G1 command may now have up to eight S parameters to specify the laser power at uniform intervals along the move (raster clustering) ** NOTE: this has not been tested yet **
The maximum length of a string expression is increased from 100 to 256 characters. Filenames are still limited to 120 characters.
Firmware version numbers now conform to Semver 2.0.0, however we are not following the Semver standard for major version number increments on breaking changes.
RRF now recognises filament usage string in GCode files generated by S3D version 5
Functions min() and max() can now be applied to a single parameter of array type
Added function "vector(numElements, elementValue)"
Added option for the echo command to append to a file without adding a terminating newline, echo >>>filename ...
If any error messages are generated during startup when processing config.g, the first such message is saved along with its line number and made available via the object model and M122
When a print file completes normally then file stop.g is run automatically even if the print file did not end with a M0 command
Previously, when M0 was sent from the console when there was no SD card print in progress or paused, file stop.g was run. This was never intended behaviour. File stop.g is now only run when a print completes.
If an array-valued item is used as an argument to the echo command, the array elements are now displayed inside [ ] instead of displaying [array].
New function fileexists(filename) is now available in conditional GCode
In menu files for 12864 displays the V (visibility) parameter in any menu item may now be an object model expression enclosed in { } returning a Boolean value, as an alternative to one of the existing numeric codes. The N (item number) parameter in a "value" menu item may now be an object model expression enclosed in { } representing the value to be displayed, as an alternative to one of the existing item codes.
[Hangprinter kinematics] Various improvements have been made
[Duet 2] Pins "connlcd.5", "connlcd.6", "connlcd.7", and "connlcd.8", "connlcd.9" and "connlcd.10" are now available for GPIO if no display is connected to connlcd and they are not being used to support additional stepper drivers
[Duet Maestro] Neopixel LED strips are now supported in principle, however this has not been tested. Note, most Neopixel strips require a 5V control signal, whereas the Maestro only provides 3.3V.
[Duet 2] The amount of free RAM has been increased
[Duet 2 WiFi] [Duet 3 Mini WiFi] [Duet 3 MB6HC with WiFi module] If M587/M588/M589 is commanded while the WiFi module is trying to connect, RRF now rejects the command with an error message, to avoid getting SPI timeout messages
[Duet 2 WiFi] [Duet 3 Mini WiFi] [Duet 3 MB6HC - version 1.02 with WiFi module] Added functions M587.1 and M587.2 to scan for and list available WiFi networks (needs WiFi firmware version 2.1.0).
[Duet 3] When processing job files, commands for both motion systems are now processed by the primary file stream by default. The secondary file stream is only activated if the M606 command is used, which can be done in the job file or in the start.g.file. When the job completes the secondary file stream is closed and commands in the stop.g file for both motion systems are executed by the primary stream.
[Duet 3] 'abort' commands are no longer executed by the inactive file channel
[Duet 3] New M606 command supported to fork the input stream when running a job from SD card. This command must be used in the job file if you want the second input stream to execute commands for the second movement system; otherwise commands for both movement system are executed by the primary file stream.
[Duet 3] In Duet 3 main boards with Ethernet interface, TCP sockets now support backlogs
[Duet 3] When a CAN-connected expansion board has registered its presence with the main board, if the main board stops receiving status messages from the expansion board then an event of type expansion-timeout is raised; or if the expansion board sends a new announce message (indicating that it has reset) an event of type expansion-reconnect is raised.
[Duet 3] Expansion and tool boards can now generate debug output, which is relayed to the DWC console
[Duet 3] Increased maximum number of general purpose outputs from 32 to 64
[Duet 3] Increased maximum number of general purpose inputs from 32 to 56
[Duet 3] Increased maximum number of fans from 20 to 32
[Duet 3] Increased the maximum open file count from 10 to 20
[Duet 3] When running a job from file, 'echo', 'global' and 'set global....' commands are only executed by the currently-selected motion system
[Duet 3] Added MQTT publisher support to Duet 3 boards with WiFi support
[Duet 3] M599 (keepout zone) is now supported
[Duet 3 Mini] The maximum number of CAN-connected expansion boards and CAN-connected drivers have both been increased to 8
[Duet 3 Mini] Pins on the 12864 LCD connector are now available to use as general purpose output when no LCD is connected
[Duet 3 Mini] Pins spi.cs1 and spi.cs2 now support interrupts and can be used as inputs. In particular, this allows an accelerometer INT output to be connected to one of these pins.
[Duet 3 Mini] [EXP3HC] [TOOL1LC] [EXP1XD] [EXP1HCL] The generation of interrupts from input pins is now deglitched using a 1MHz clock instead of a 120MHz or 48MHz clock, to better suppress short glitches
[Duet 3 MB6HC] [Duet 3 MB6XD] [Duet 2] [Duet Maestro] PWM resolution when using outputs connected to the PWM peripheral is increased
[Duet 3 MB6HC] [EXP3HC] [EXP1HCL] M569.7 now allows brake voltage to be selected
[Duet 3 MB6HC] [Duet 3 MB6XD] The maximum number of axes has been increased to 30. The maximum number of axes+extruders has been increased to 32. Axis letters XYZUVWABCD and a..z may be used when using these boards.
[Duet 3 MB6HC] [Duet 3 MB6XD] [Duet 3 Mini] [EXP3HC] [SAMMYC21] BME280 temperature/pressure/humidity sensors connected via SPI are now supported
[Duet 3 MB6HC] [Duet 3 MB6XD] [Duet 3 Mini] New subfunction S4 of G29 allows selective probing for a height map
[Duet 3 MB6HC] Support for add-on WiFi module has been added to version 2
[Duet 3 MB6XD] Added detection of the MB6XD version 1.01 board
[M23CL] [TOOL1RR] [SZP] The Duet closed loop motor M23CL, Revo Roto tool board (TOOL1RR) and scanning Z probe (SZP) are now supported
[EXP1HCL] Duet3D magnetic shaft encoders are now supported
[EXP1HCL] Linear quadrature encoders are now supported. The motor must also have a Duet 3 magnetic shaft encoder.
[EXP1HCL] [M23CL] Changes to the closed loop algorithm reduce motor noise in closed loop mode
[EXP1HCL] [M23CL] Added acceleration feedforward term to closed loop PID parameters and M569.1
[EXP1HCL] [M23CL] Added an experimental Assisted Open Loop mode
[EXP1HCL] [M23CL] Failed-to-maintain-position warnings did not generate events; they now generate driver-warning events
[EXP1HCL] [M23CL] Added experimental velocity feedforward parameter V to the existing M569.1 PID parameters. The default value is zero. Note, the standard step tuning move does not use this parameter, therefore if you use a nonzero value then you need to use a regular G1 move instead when you perform PID tuning.
[TOOL1LC] [SAMMYC21] LDC1612-based scanning inductive sensors are supported (Z probe type 11)
[EXP1HCL] Torque mode is supported
[EXP1HCL] Version 2.0 prototype boards are supported
[TOOL1LC] [EXP1XD] Speeded up motion calculations a little by using a faster floating point square root function
[TOOL1RR] Additional functionality has been enabled on the TOOL1RR board (to be confirmed)

Internal changes:

Upgraded to FreeRTOS 11.0.1. Task wait/notify functions now use indexed notification.
Upgraded FatFs from version 0.14b to 0.15 patch 3
Added auto detection of WiFi module type in WiFiFirmwareUploader. This does not include selecting the correct WiFi firmware binary automatically.

New object model fields:

boards[].accelerometer.orientation
boards[].drivers[] is added for any expansion boards that have a nonzero number of drivers. This key always has field 'status' which is the status of the driver encoded as a 16-bit integer. If the driver is a Duet3D closed loop driver then boards[].drivers[] also contains subkey 'closedLoop' which in turn has subkey 'currentFraction' with fields 'avg' and 'max', and subkey 'positionError' with fields 'max' and 'rms'. All four of these values relate to the values seen by the closed loop driver over the previous 250ms interval. These fields are experimental and subject to change.
boards[].freeRam
boards[0].directDisplay.encoder.pulsesPerClick
boards[0].directDisplay.screen. { contrast, controller, height, spiFreq, width } and for ST7267 displays also { resistorRatio, colourBits }
fans[].sensors[] (integer array)
fans[].tachoPpr
heat.heaters[].monitors[].sensor
heat.heaters[].maxBadReadings (integer)
heat.heaters[].maxHeatingFaultTime and heat.heaters[].maxTempExcursion (float)
inputs[].active (true if the input is is in active mode i.e. executing commands, false if it is assigned to a motion system other than the current one). This will always be true except for the File and File2 inputs.
inputs[].inverseTimeMode (Boolean)
inputs[].motionSystem (integer, only on builds that support multiple motion systems)
inputs[].selectedPlane (integer)
job.lastWarmUpDuration (integer, in seconds)
ledStrips[] and seqs.ledStrips
limits.portsPerHeater
limits.ledStrips
move.axes[].backlash (float, the configured backlash compensation for the corresponding motor in mm)
move.backlashFactor (integer, the configured M425 S parameter)
move.currentMove.extrusionRate (float, returns the current total extrusion rate in mm/sec)
move.extruders[].filamentDiameter (float)
move.keepout (list of keepout zones)
move.shaping.reductionLimit (replaces move.shaping.minAcceleration)
network.interfaces[].ssid (only when the interface is WiFi and it is connected to an access point)
sensors.analog[].state (string, returns "ok" if the sensor is working, otherwise a short description e.g. "openCircuit")
sensors.analog[].{ offsetAdj,slopeAdj }
sensors.analog[].{ rRef } for locally-configured thermistors, PT100 and PT1000 sensors only
sensors.analog[].{ beta,c,r25,rRef } for locally-configured thermistors only
sensors.analog.port for locally-configured sensors only
sensors.filamentMonitors[].enableMode (value is 0, 1 and 2 to match the S parameter of the most recent M591 command for that extruder)
sensors.filamentMonitors[]. { avgPercentage, lastPercentage, maxPercentage, minPercentage, totalExtrusion } (laser and magnetic filament monitor only; only present if the filament monitor is enabled and calibration has completed)
sensors.probes[].diveHeights[] (array of two elements)
sensors.probes[].measuredHeight (reported for scanning Z probes only)
sensors.probes[].scanCoefficients (either null or an array of four elements)
sensors.probes[]. { calibA, calibB, isCalibrated } (for scanning Z probes only)
spindles[].idlePwm, spindles[].minPwm and spindles[].maxPwm (float)
state.gpOut[].freq (integer, the configured PWM frequency of the port)
state.startupError which is either null or contains fields message (string), file (string) and line (integer) corresponding to the first error message that was generated during startup.
state.thisActive (boolean, shorthand for inputs[state.thisInput].active)

Changed object model fields:

sensors.probes[].scanCoefficients[] values are now reported to 7 decimal places
network.interfaces[].state now takes new value "idle" if the interface is WiFi and the module is idle (e.g. after M552 S0). Previously it reported "active" for this state.
state.gpOut[].pwm increased the reported precision from 2 to 3 decimal places
move.axes[].machinePosition is now updated during moves. The maximum update rate is once every 200ms.
move.extruders[].pressureAdvance is now reported to 3 decimal places
network.interfaces[].mac is no longer populated if the interface is a WiFi interface and it is disabled. In previous firmware versions, incorrect data was returned when the WiFi module had not been enabled.

Object model fields flagged 'obsolete' and scheduled for removal in a future release:

sensors.filamentMonitors[].enabled
fans[].heaters[] (use fans[].sensors[] instead)
sensors.probes[].diveHeight (use sensors.probes[].diveHeights[0] instead)-.

Object model fields removed (were mostly flagged as obsolete since firmware 3.3):

boards[0].directDisplay.{ pulsesPerClick, spiFreq, typeName } (replaced by boards[0].directDisplay.encoder.pulsesPerClick and boards[0].directDisplay.screen.{ colourBits, controller, height, spiFreq, width }).
directories.scans
job.firstLayerDuration
job.timesLeft.layer
move.compensation.probeGrid.{axis0, axis1, xMin, yMin, xMax, yMax, xSpacing, ySpacing} (use axes[], mins[], maxs[], spacings[] instead)
move.workspaceNumber (use move.workplaceNumber)
move.shaping.minAcceleration
sensors[].probes[].speed (use sensors[].probes[].speeds[1] instead)
sensors[].probes[].temperatureCoefficient (use sensors[].probes[].temperatureCoefficients[0] instead)

Bug fixes:

Removed some code that enabled the SBC interface when running in standalone mode, because it no longer works and it can cause a hard fault if there is noise on the slave select line
Incorrect motor steps were sometimes generated on delta printers, typically resulting in leaning prints
param.K was not passed to retractprobe.g
Scanning Z probes used as regular probes did not work for G30 commands with a P parameter
Reading the coolStep register from TMC2209/TMC2240/TMC2160/TMC5160 drivers returned data from the wrong register
On Duet Ethernet and Duet Maestro the reduction in the number of TCP connections available for HTTP protocol in rc3 when FTP and/or Telnet protocols were disabled caused network connectivity issues on some systems, mainly with browsers running under Linux or MacOS. The functionality to make additional HTTP sockets available when FTP and/or Telnet protocols are disabled has been restored.
On the 12864 display a button menu item with an action of the form A"M98 P#0" L"filename" no longer worked because the filename substituted for #0 was not enclosed in double quotes; also any text in the A parameter after #0 was ignored.
When both input shaping and pressure advance were used, the timing of extruder motor steps towards the end of a decelerating move was sometimes incorrect
Input shaping was sometimes applied incorrectly, which could result in layer shifts
Evaluation of exists(global.varname[index]) and exists(var.varname[index]) returned the element value instead of 'true' if the index was in range, and threw an error if the index was out of range (issue 958).
In the M36 JSON response the height and width values of thumbnail data were swapped
In rare situations running M122 could cause a "Stuck in spin loop" board reset
M220 and M221 speed adjustments were not applied to feed rates in movement commands in user macros
The values of the fields of move.rotation in the object model were incorrect, typically zero even if G68 had been used
Linear analog sensors were not supported on main boards used as expansion boards
Fixed pause/resume when multiple motion systems are used in a job
When Neopixel strings were used with Duet 2 the colour of the first LED in the strip was often incorrect
In standalone mode the fileRead function could not be used with a delimiter of '.' because a '.' after a digit string was treated as a decimal point instead of as a delimiter
Rarely, running M122 would hang the main board or expansion board it was run on, causing the board to reset
Object model variable seqs.sensors was not updated after M558.1 was run, therefore some sensors.probes[] values in the DWC and DSF copies of the object model became stale
M595 with some stupidly large parameter values caused an Out-of-Memory reset instead of reporting insufficient memory (issue 939)
M204 accepted very small or negative parameter values
After switching to laser mode using M452 the firmware would sometimes reset when executing the next movement command
If M574 was used to configure a Z probe to be used as an endstop, homing moves using that endstop caused the firmware to reset
Using extruder stall detection for filament loading (G1 H1 E moves) still didn't work
When passing parameters to a M98 or G29 or G31 command, if an error occurred while parsing a parameter value then the error was ignored and the parameter was given a null value.
Increased the maximum length of the pin names string in the M574 command from 50 to 61 characters (issue 881)
If the FTP server received a LIST command with an argument but there was no directory matching the argument (e.g. "LIST -a") then no error was returned
When running a job the file position reported in the object model was sometimes wrong (typically very large) just after a macro had completed
When a while-loop was executed, line numbers reported in the body of the loop were too high by one during the second and subsequent iterations
When a keepout zone was defined some G2 commands were not recognised as intruding into the zone
Extra indentation following a M291 command inside an if-block could cause a further nested if-block not to execute (https://github.com/Duet3D/RepRapFirmware/issues/897)
If the maximum number of elements permitted in a literal array is exceeded, a separate error message is used instead of reporting that a closing brace was expected
When a GCode command resulted in the job being aborted, the line number of the command concerned was not reported in the error message
When the value of an array was echoed there was a spurious trailing comma
On IDEX machines a tool change sometimes resulted in spurious movement of the old tool when the new tool was being positioned
If M291 was used to produce a lot of messages from more than one input channel, stack overflow messages could be generated
For TMC2160/5160 drivers the over-temperature pre-warning and over-temperature error indications were swapped
Passing parameters with negative values in M98 commands didn't work
If a M291 S1 message box was closed in DWC manually before it timed out, a spurious M292 error message was generated
When setting the gateway and/or netmask for an Ethernet interface manually, the gateway and netmask values were swapped
If a print was paused when the speed factor was not 100% then when the print was resumed, the speed factor was applied again until a G0/1/2/3 command with F parameter was executed
G2/G3 moves for which the complete circle would infringe and keepout zone sometimes caused an assertion failure leading to a reset
"echo tools" return an incorrect string
M669 behaved unexpectedly when more matrix columns than configured axes were supplied
Using N{expression} in a 12864 display menu file didn't work
Error handling for array indices in set command was missing in SBC mode leading to potential unexpected resets
It was not possible to use extruder stall detection for filament loading
M28 removed leading spaces and tabs
M669 with a S or T parameter that was not followed by a digit caused the firmware to reset
If a G31 command had two T (temperature coefficient) parameters but the first one was zero, then G31 with no parameters or with just a K parameter did not report either of them
If a GCode command had a bad parameter then movement might be locked (e.g. after sending M593 P"mzv" F"40") until another command was sent from the same channel
When estimating the print time remaining based on a previous simulation, RRF did not allow for heating up time while executing M109
M3 and M4 commands to change the speed of a spindle that is not used by the active tool were sometimes ignored
M587.2 did not return the correct authentication values
M587.2 returned truncated SSIDs
M587.2 did not always return the complete list of access points found
while-loops did not return to the correct loop starting position if the macro file used CRLF line endings
Spurious filament monitor events from expansion boards were sometimes generated when RRF started
When starting a print, DWC and PanelDue did not always update the displayed information for that file, depending on the file contents
The reduced accelerations set by M201.1 or their default values were used when executing special moves even if they were higher than the normal M201 values
When running a job or macro file that used CRLF as the line ending, the line number was incremented twice per line
When M500 P10 was run the G10 tool offset lines added to config-override.g has spurious 0.0 values at the end
When two M569.5 commands were sent in quick succession so that the first one was still in progress when the second one was sent, if the rate of data collection was high then the board would sometimes reset with a memory protection fault
If temperature sensors were added or removed while an extruding move was being started, a reset might occur
If temperature sensors were added or removed while Z probing and a trigger height temperature coefficient was in use, a reset might occur
If a FTP client executed a CHUP command that moved to the root directory, a subsequent PWD command returned path "" instead of "/"
If only one of the X any Y axes had been homed and a normal move along that axis was commanded when nonzero G68 coordinate rotation was in effect, the move should have been rejected because it involved moving the un-homed axes
A rr_model or M409 object model query with a key of the form "global.myvar" reported on all global variables, not just the requested one
A rr_model or M409 object model query ignored an attempt to select a member from or index into a value of a primitive type. For example, a request for "state.currentTool[0]" returned the value of state.currentTool instead of null.
It was already prohibited to assign an object value to a variable using the set command, however the check for creating a variable with an initial object value was missing. If you did create such a global variable (e.g. "global a1=move.axes[1]") then DWC looped trying to connect because RRF returned bad JSON.
When evaluating expressions, #global.xxx where the value of xxx is a string returned the string instead of the length. #(global.xxx) worked correctly.
When a job was paused or power was lost and a tool spindle was turning, the resurrect.g file did not include the commands needed to restore the spindle speed and direction
[Duet 2 Ethernet] [Duet Maestro] Under conditions of high load, TCP connections could become stuck. This eventually resulted in loss of communication until either the board was restarted or one of the network protocols was stopped ands restarted using M586.
[Duet 2] [Duet Maestro] [Duet 3 MB6HC] [Duet 3 MB6XD] If a large amount of data was received through the USB port than some data could occasionally be lost
[Duet 2 Ethernet] [Duet Maestro] When M586 was used to enable to disable any network protocol, or to change the port number used by an enabled protocol, all TCP/IP connections were terminated and had to be re-established (issue 944)
[Duet 3] When two or more tool or expansion boards had filament monitors attached and a print was done that used both of the associated extruders, non-movement commands sent to tool or expansion boards could return CAN timeout errors
[Duet 3] A spurious "Invalid handle" error was reported when creation of a Z probe on an expansion board failed
[Duet 3] When a Duet 3 main board was used as an expansion board, with some print files a memory leak would occur which could eventually cause the board to reset with an Out Of Memory error recorded in the M122 software reset data
[Duet 3] The B parameter passed to filament-error.g when a filament event occurred was always zero
[Duet 3] M952 didn't accept parameter B0
[Duet 3] If several M569.5 closed loop tuning commands were issued in rapid succession, the Duet might reset
[Duet 3 MB6HC] [Duet 3 Mini] A PanelDue or other device using the same protocol attached to the second serial port did not work
[Duet 3 MB6HC] [Duet 3 MB6XD] If many axes were configured then the 'move' part of the object model might be too large to send, causing DWC or PanelDue to disconnect and not be able to reconnect
[Duet 3 MB6HC] [Duet 3 Mini] MDNS name lookup didn't work from some Mac and Linux PCs
[Duet 3 MB6HC] When the optional WiFi module was installed, command M552 I1 S1 in config.g often failed to enable it, even though it worked when sent manually
[Duet 3 MB6HC] [Duet 3 MB6XD] [Duet 3 Mini Ethernet] Fixed mDNS support
[Duet 3 MB6HC] [Duet 3 MB6XD] [Duet 2] [Duet Maestro] On the PWM peripheral, PWM frequencies down to 1Hz are supported again
[Duet 3 MB6HC - version 1.02 with WiFi module] If M552 was used to put the WiFi module into idle or disabled mode, any existing Ethernet HTTP sessions were disconnected temporarily
[Duet 3 MB6HC - version 1.02 with WiFi module] If the WiFi module had never been enabled then M112 displayed uninitialised values for the WiFi error counts
[Duet 3 MB6HC - version 1.02 with WiFi module] If the reset button was used to reset the Duet then the WiFi module was not reset
[Duet 3 Mini] Under certain conditions the USB port could become unresponsive, for example if M575 P0 S0 was used to reinitialise it
[Duet 3 + SBC] If the SBC connection was reset while the Duet was attempting to send data to it for writing to a file (e.g. closed loop tuning or accelerometer data) then the Duet might reset due to a Hard Fault
[EXP1HCL] The M569.2 command to read stepper driver registers was not supported
[TOOL1LC] [TOOL1RR] [EXP3HC] When a M591 command was used to report on a magnetic or pulsed filament monitor connected to an expansion board, an extra newline character was appended to the response
[TOOL1LC] Very short moves could cause extrusion to stop during printing moves although extruder-only movement still worked
[TOOL1LC] In some configurations the board would reset with an Out Of Memory error, especially when using the more advanced forms of input shaping

RepRapFirmware 3.5.0 stable (changes since 3.4.6)

This release had an issue that caused incorrect motion when a M400 command was used in a deployprobe.g or retractprobe.g file. Because of the potential for damage when this issue occurred, we have withdrawn the 3.5.0 release.

RepRapFirmware 3.4.7 (in preparation)

Upgrade notes: none since 3.4.6

Bug fixes:

Fixed incorrect setting of gateway IP address and netmask on Ethernet interfaces
Under certain circumstances DSF could miss a notification from RRF when a print completes
Fixed incorrect file position just after a macro file terminates
Fixed incorrect line number (off by 1) within a while-loop in conditional GCode
Fixed truncation of M591 response with magnetic and laser filament monitors
Fixed spurious index-out-of-bounds error when indexing into arrays within arrays, e.g. move.axes[2].drivers[3]
Fixed motor movement after M112 Emergency Stop in some configurations
Fixed possible hang when M122 is run on an expansion board

Internal changes:

Added missing #include directive needed when compiling with later versions of gcc

RepRapFirmware 3.4.6

Upgrade notes:

Previously, when stall detection was configured using option R2 or R3 in the M915 command, stall events were only generated when running a job from file. Now they are also generated when not running a job from file. You can use conditional GCode in the driver-stall.g file if you wish to ignore stall reports when not running a job from SD card.

New features since 3.4.5:

Increased pressure advance reporting to 3 decimal places in object model queries
Increased tool offset precision to 3 decimal places when writing G10 commands to config-override.g
When assembling data to bit-bang to Neopixel LEDs, don't wait for motion to stop until data for all the LEDs has been assembled
When the main board executes a stuck-in-spin-loop or heat-task-stuck software reset it now saves the relevant stack entries in the software reset data
On processors with hardware floating point support, the stack trace after a reset no longer includes the floating point registers, leaving room to report more useful stack entries
The web server now supports absolute HTTP URI requests
In CNC and laser modes, implicit G2 and G3 commands are once again supported
When stall detection is enabled, stall events are generated even when not executing a GCode job from file
The filament length comments in GCode files generated by Simplify3D version 5.x are now recognised
Increased the amount of the GCode job file that we scan at the start, to allow for larger thumbnail images
[Duet 3 MB6XD] Version 1.01 boards are supported
[Duet 3 MB6HC] [Duet 3 MB6XD] Increased the maximum number of TCP sessions supported from 8 to 10
[Duet 3 Mini] Pins spi.cs1 and spi.cs2 now support interrupts and can be used as inputs. In particular, this allows an accelerometer INT output to be connected to one of these pins.
[Duet 3 Mini] Most of the pins on the LCD connectors can now be used as general purpose output when they are not used to connect a 12864 LCD
[Duet 3 Mini] [Duet 3 EXP3HC] [Duet 3 TOOL1LC] [Duet 3 EXP1XD] [Duet 3 EXP1HCL] The generation of interrupts from input pins is now deglitched using a 1MHz clock instead of a 120MHz or 48MHz clock, to better suppress short glitches

Bug fixes:

When a FTP CDUP command reached the root directory a subsequent PWD request returned an empty path instead of "/"
The CAN board address was incorrect in a filament-error event
If M574 commands were executed frequently then the Duet would occasionally reset with a "stuck in spin loop" software reset code
The M952 command did not accept parameter B0
Increased the maximum length of the pin names string in the M574 command from 50 to 61 characters (issue 881)
The minimum accepted value of the S parameter in the M556 command is reduced to 1.0 (was 10.0)
Fixed issue with G53 not exactly removing the tool offset if axis scale factors were used (issue 883)
Fixed a memory leak when a main board was used as an expansion board
When starting a new print, DWC would occasionally be given incomplete information for the new print file, which caused it to report incorrect data and print progress for the new print file
When performing probing or stall homing moves, don't use the M201.1 acceleration parameters if they are higher than the M201 parameters
Fixed incorrect GCode file and macro file line numbers in error messages (double counting) when the line ending was CRLF
Don't write additional 0.00 fields (that corresponded to non-existent axes) when writing G10 commands to config-override.g
Fixed main board reset when two closed loop data collection commands were sent quickly in succession
Fixed incorrect board CAN address reported in filament-error events
M952 command didn't accept zero as the B (board address) parameter
Fixed FTP failures with some FTP clients after the client uses the PWD command to select the root folder of the SD card
Allow the speed of an inactive spindle to be changed
Fixed unexpected reset when the M669 S parameter was not followed by a number
When a command that normally locked movement had invalid parameters and the command was rejected, movement could remain locked until a successful command was executed by the same input channel
If the config.g file contained a M291 S2 command to display a message box at startup, at the end of config.g various state variables (e.g. whether extrusion is relative or absolute, the default feed rate, whether mm or inches are used in coordinates) were not copied to all input channels as they should have been
When M28 was used to upload a file, leading spaces were removed, which was a problem if the file included if- or while-commands
Warm-up time was not counted when a M109 command was used to wait for extruder temperature to be reached
If a nonzero speed factor was applied, after pausing and resuming the job the speed factor got applied again
When non-unity axis scale factors were used, using G53 didn't entirely eliminate the effect of tool offset from the following G0/1/2/3 command(s)
[Duet 2 WiFi] [Duet 3 Mini WiFi] Before the WiFi module had been enabled, M122 reported random large numbers of WiFi errors
[Duet 3 MB6HC] [Duet 3 MB6XD] [Duet 3 Mini Ethernet] mDNS support did not always work
[Duet 3 MB6HC - with optional WiFi module] M552 I1 S1 in config.g did not enable the WiFi module
[Duet 3 MB6HC - with optional WiFi module] When using WiFi firmware 2.1beta4 incorrect reporting of the wifi version caused DWC to connect and disconnect repeatedly

RepRapFirmware 3.4.5

Upgrade notes:

The firmware files for Duet 3 expansion and tool boards have not changed, therefore they remain at version 3.4.4.

Bug fixes:

If an event was generated when there was already another unprocessed or in-process event with the same type, CAN source address and parameter, then the new event was usually added to the pending event queue even though it should have been discarded. If an event source generated repeated events at a high rate, this could lead to an Out Of Memory reset.
If a rr_gcode command string received from DWC or another HTTP client was too long to fit in the HTTP input buffer, the command string was discarded without any error message. Under these conditions, {err:1} is now returned.
[Duet 3 MB6HC] Some revision 1.02 boards would not connect to SBC
[Duet 3 MB6HC] [Duet 3 MB6XD] When updating firmware using M997 (e.g. from DuetWebControl) the IAP program would occasionally fail leaving the firmware erased and needing to be reinstalled using Bossa. The fix for this is in the Duet3Firmware_SDiap32_xxx, Duet3Firmware_SBCiap32_xxx and Duet3Firmware_CANiap32_xxx files, where xxx = MB6HC or MB6XD.
[Duet 2 SBC build] Accelerometers were not supported

RepRapFirmware 3.4.4

Upgrade notes: none since 3.4.1

New features:

[Duet 3 MB6HC] [Duet 3 MB6XD] [Duet 3 Mini] When M569.1 is used to select the encoder type for a closed loop driver on an expansion board, the S parameter is now included for compatibility with version 3.5 expansion board firmware.

Bug fixes:

[Duet 2 WiFi] [Duet 3 Mini WiFi] If HTTP, FTP and Telnet protocols were all enabled then the network became unresponsive. This has only been observed on the Duet 2 WiFi but might also affect the Duet 3 Mini WiFi under some conditions.
[Duet 3 MB6HC] [Duet 3 MB6XD] If multicast discovery protocol was enabled and multiple discovery requests were performed, after a number of requests were processed the network became unresponsive.
[Duet 3 MB6HC] [Duet 3 MB6XD] When a main board was used as an expansion board the M122 drivers report included a partial report for non-existent driver 6.

RepRapFirmware 3.4.3

Upgrade notes: none since 3.4.1

New features:

[Duet 3 expansion boards] When a motor brake is configured for a motor connected to an expansion board there is now a 50ms delay after it is disengaged (e.g. by M17) and a 100ms delay after it is engaged (e.g. by M18)
[Duet 3 MB6HC] Improved error message when M950 D parameter is used while in SBC mode
[Duet 3 MB6HC] Changes for compatibility with latest ATE firmware
[Duet 3 MB6HC] Support forthcoming version 1.02 hardware revision including optional WiFi module

Bug fixes:

Removed no-longer-used M570 S parameter
[Duet 3 MB6XD] When an axis move using only CAN-connected drivers was terminated by a Z probe or endstop triggering, RRF attempted to revert the axis position to the position at the start of the move

RepRapFirmware 3.4.2

Upgrade notes: none since 3.4.1

New features:

When configuring a PT100 sensor using M308, the optional R parameter (reference resistor) can now include fractional parts.
Increased the number of decimal places provided for temperature readings in the object model from 1 to 2
[Duet 3 + expansion boards] When M915 is used to query the stall configuration of a driver on a CAN-connected expansion board, the response now includes whether or not an event is generated when the drive stalls
[Duet 3 Mini WiFi] File upload speed over WiFi has been improved a little. Part of the improvement is in a new build of DuetWiFiServer, version 1.27.
[Duet 3 Mini + SBC] SPI transfers between the Duet and the SBC are now more efficient. This may give some improvement in maximum throughput.
[Duet 3 MB6HC] [Duet 3 MB6XD] [Duet 3 Mini] Implemented firmware update via CAN when a main board is used as an expansion board (needs the appropriate Duet3_CANiap32_*.bin file in the /firmware folder of the SD card in the expansion board)
[Duet 3 MB6XD] Maximum step pulse width is increased from 3495 to 13980 microseconds to facilitate testing in the ATE
[Duet 3 MB6XD] Driver error events are no longer created when the board is in ATE testing mode
[Duet 3 MB6HC] [Duet 3 MB6XD] Multicast discovery protocol is now supported. This is an OEM-defined protocol; we recommend that most users use mDNS instead to discover Duets on a network.
[Duet 3 EXP1HCL] When a magnetic encoder is used, M122 reports additional diagnostic information

Internal changes:

Updated the linker command lines so that RRF and Duet3Expansion projects can be build in Eclipse 2022-06 (as well as in earlier versions)
Input conversion functions no longer use 'pow', to save flash space

Bug fixes:

Duet 3 main boards used as CAN-connected expansion boards generated events when a driver stalled even if they were not configured to do so
The firmware build times reported by M115, M122 and M122 in expansion board mode differed by a few seconds
The ACT LED on Duet 3 main boards flashed continuously if a fan was configured on any expansion board
Under certain conditions an extrusion-only move was executed at maximum speed instead of the requested speed
When both spaces and tabs were used to indent GCode commands, the warning message generated did not end in newline
Some messages did not use the correct case in units, for example Gb was used for Gigabytes
In CNC mode G0 moves were limited to 300mm/sec. This has been increase to 1000mm/sec.
If a thermostatic fan was configured to trigger on the temperature of a heater that did not exist, the fan was left off. It is now turned on.
File uploads over the network using FTP sometimes failed without warning. This bug may also be responsible for the occasional reported disappearance of the config.g file after it is edited in DWC.
When evaluating expressions in conditional GCode, some string comparison operations resulted in a memory leak. This could result in an out-of-memory reset if a string comparison was performed in a loop.
When the last line of a macro file belonged to an inner block, and that macro file was called from another one, unexpected behaviour could occur because the inner blocks were not exited cleanly
Events were reported to the console even when there was a macro to handle the event
[Duet 3] Main boards used as CAN-connected expansion boards generated events when a driver stalled even if they were not configured to do so
[Duet 2 WiFi] [Duet 3 Mini WiFi] When WiFi firmware 2.0beta was installed, SPI timeout errors would be reported when starting the WiFi module
[Duet 3 with CAN-connected expansion boards] configuring a thermostatic fan on an expansion board that uses a sensor on a different board did not work properly.
[Duet 3 MB6HC] [Duet 3 MB6XD] [Duet 3 Mini] When a main board was used as an expansion board there were a number of issues affecting clock synchronisation and movement of attached stepper motors
[Duet 3 MB6HC] [Duet 3 MB6XD] [Duet 3 Mini] When the main loop time was high (e.g. during startup) the STATUS LED on the main board did not flash at the correct rate
[Duet 3 MB6XD] The ACT LED was not driven
[Duet 3 MB6XD] If M122 was run while a move using very high step rates was in progress, the step rate might slow down drastically for the remainder of the current move. If the move was long then the CPU might be starved of cycles, leading to a software reset. Duet 3 MB6HC and Duet 2 boards might exhibit this behaviour too.
[Duet 3 MB6XD] If a step pulse width greater than 3495 microseconds was requested then the step pulse interval and direction hold time was processed incorrectly, as evidenced by the reported actual times
[Duet 3 MB6XD] M915 was not supported, so the stall parameters of drivers on CAN-connected expansion boards could not be set
[Duet 3 MB6XD] M917 was not supported, so the standstill current percentage on expansion board drivers could not be set

RepRapFirmware 3.4.1

Upgrade notes:

[EXP1HCL] Duet 3 1HCL version 0.3 boards are no longer supported.

New features and behaviour changes:

RRF no longer emits a "Possible virus attack" message when the HTTP server receives a request for a very long filename
[Duet 3 MB6XD] The version 1.0 production boards are supported as well as the version 0.1 pre-production boards
[Duet 3 EXP3HC] The forthcoming version 1.02 board is supported (older firmware versions will report the VIN voltage incorrectly on the new boards)
[Duet 2 Ethernet] [Duet Maestro] File upload speeds are slightly lower than in previous versions
[Duet 2] [Duet Maestro] The number of output buffers has been increased from 24 to 26. This may address issues with the network connection being lost when the machine configuration is complex.
[Duet 3 MB6XD] The driver error inputs now have pin names so that they can be read directly
[Duet 3 Mini WiFi] If the RTOS-based WiFi module firmware is detected then the SPI speed is increased to 40MHz
[Duet + SBC] Improved SPI error handling and error recovery

Object model changes:

Fields state.previousTool and state.nextTool are no longer flagged 'live', however seqs.state is incremented when they change

Bug fixes:

M581 P parameter did not allow multiple comma-separate values enclosed in { }
When a heater fault event was generated on the main board, the heater number and CAN address parameters were swapped. This resulted in the heater number always being reported as 0.
When a filament error event was generated on the main board, the extruder number and CAN address parameters were swapped. This resulted in the extruder number always being reported as 0.
In the M957 command it was necessary to use the underscore character '_' in event names in place of the dash character '-'. Both are now accepted.
When the M309 command was used without a tool number and there was no current tool, the error message was "Invalid tool number" instead of the more descriptive one intended
When an object model expression that is represented in RRF as a bitmap was indexed in a context other than from the key parameter of M409 or rr_model, the indexing operator did not always yield the correct result. For example, "echo tools[1].fans[0]" typically yielded the wrong value.
When M20 S2 or M20 S3 was run from an input channel in Marlin emulation mode, the response was surrounded by "Begin file list ... End file list" even though it was in JSON format
M592 nonlinear extrusion didn't work because the A and B coefficients were interpreted in the wrong units
G60 did not increment seqs.state to signal that restore points had changed
When the print was paused it did not increment seqs.state to signal that the pause restore point changed
[Duet 2 Ethernet] [Duet Maestro] Uploads of large files sometimes failed with CRC errors, especially if a print or simulation was in progress
[Duet 3 MB6HC] [EXP3HC] The stepper driver open load status bits were supposed to be ignored until they were set in two consecutive readings, however this was not always the case
[Duet 3 with CAN-connected expansion boards] If all the tower motors of a delta printer were driven from CAN-connected expansion boards, then when the Z probe was triggered the tower motors failed to stop. Note, driving the tower motors of a delta via CAN is not supported in RRF 3.4.x and earlier, but might work if segmentation is used.

RepRapFirmware 3.4.0

Upgrade notes:

The handling of filament errors has changed. When a filament error occurs, an event is created. To handle the event, RRF runs macro file filament-error.g without appending the extruder number to the file name and without pausing the print first. The extruder number is passed as param.D along with some other parameters. If filament-error.g is not found then the print is paused (running pause.g) and the error is reported.
The handling of driver stalls has changed. In the M915 command there is no longer a distinction between R2 and R3; both cause an event to be created when the driver stalls. To handle the event, RRF calls driver-stall.g passing the stalled local driver number in param.D and the CAN address of the board concerned in param.B. File rehome.g is no longer used. If file driver-stall.g is not found then the print is paused without running pause.g and the error is reported.
The handling of heater faults has changed. When a heater fault occurs, an event is created. To handle the event, RRF runs macro file heater-fault.g without pausing the print first. The heater number is passed as param.D along with some other parameters. If file heater-fault.g is not found then the print is paused and the user is notified. Currently, RRF does not attempt to turn off power to the whole machine if the user does not respond to the heater fault. We plan to reinstate this or a similar function in release 3.5.0.
After changing tool, RRF no longer moves the new tool head to the coordinates at which the old tool head was at when the Tn command was actioned. In most situations this should not matter, because GCode generators usually generate commands to move to the correct XYZ position after generating a Tn command. Usually, they restore XY before Z. However, Cura does it the other way round, which risks dragging the tool head across the print. Therefore when using Cura, or in any other situations in which you want to restore the old behaviour, we suggest you add command G1 R2 X0 Y0 Z2 Fxxx followed by G1 R2 Z0 Fxxx to the end of your tpost#.g files, if you don't already use those or similar commands.
There is no longer a power supply control pin assigned by default (in previous firmware versions, PS_ON was assigned by default). Therefore, M80 and M81 will not work until you have assigned a power control pin. If you want to control the power supply, you should use assign a pin using either M80 or M81 with the C parameter in config.g. Use M80 if you want to start with power on, or M81 if you provide separate 5V power and you want to start with VIN power off.
Where a GCode parameter accepts multiple values, you can no longer use a mixture of literals and expressions (which was previously supported in standalone mode only). However, the whole parameter can now be an array expression, in both standalone and SBC modes. For example, M92 E{var.e1}:400:{var.e3} will no longer work and must be replaced by M92 E{var.e1,400,var.e3}.
The H parameter of the M0 and M1 commands has been removed. Heaters will always be turned off when these commands are executed; except that if M0 is used to cancel a print that is paused and file cancel.g exists, cancel.g will be run and heaters will remain on unless cancel.g turned them off. Previously, M0 H1 or M1 H1 would leave heaters turned on.
M106 with both P and R parameters is no longer supported. M106 with R parameter but no P parameter works as in release 3.3.
DHT11 temperature/humidity sensors are no longer supported. DHT21 and DHT22 sensors continue to be supported.
DAA input shaping is no longer supported in M593, so if you are using it you will need to switch to one of the new supported types of input shaping
If you create additional axes whose names are lowercase letters, the corresponding homing files for those axes now have a single-quote character in front of the axis letter in the filename. For example, after "M584 'a3" the homing file for axis "a" is "home'a.g". This is to distinguish them from the names of homing files for axes whose names are uppercase letters.
Previously, if a G- or M-code did not have any variants with fractional parts, any fractional parts would be ignored. For example, M114.1 would be treated the same as M114. Now, M114.1 will provoke a "not implemented" warning; but M114.0 will still be treated the same as M114.
[Duet 3 Mini] With BLTouch or servo Known issue: port io1.out does not work properly as a servo port. This will be fixed in the next RC. Ports io2.out and io3.out work correctly (note that io3.out is shared with the 12864 display backlight control).
[Duet 3 MB6HC in standalone mode] [Duet 3 Mini Ethernet in standalone mode] [Duet 2 Ethernet] The default MAC address will change in this release. This means that your router is likely to assign it a different IP address from the previous one. If you have a DHCP address reservation for the Duet configured in your router, you will need to update it for the new MAC address.
[Duet 3 Mini] [Duet Maestro] The stepper drivers no longer default to stealthchop mode, because of the risk of excessive motor current if the correct tuning move is not executed

New features and changed behaviour:

Input shaping types ZVD, ZVDD, ZVDDD, EI2, EI3 and MZV are supported. See the M593 command in the Duet3D GCodes wiki page. DAA is no longer supported.
Thumbnail images encoded in GCode job files in QOI or PNG formats can now be provided to Duet Web Control and PanelDue (note: PanelDue can only use QOI format). This has been done by extending the response of the M36 command and the rr_fileinfo HTTP command, and adding new commands M36.1 and rr_thumbnail.
Heater feedforward is now supported and configured using the M309 command, to increase heater power automatically in line with extrusion rate
Hobby servos can now be used with user-settable refresh frequencies (previously, only 50Hz was supported)
M291 commands are now executed as soon as they are processed. Previously, non-blocking M291 messages were delayed until previous movement commands had been completed.
M906, M913 and M917 commands with no parameters no longer wait for movement lock
When the Invert flag is used in the M307 heater model parameters, RRF no longer skips waiting for the requested temperature to be reached if the requested temperature is below 40C. Instead it skips waiting if the requested temperature is above 20C. This change has been made to better support Peltier devices used to cool a print bed below ambient temperature.
The tolerance for the actual vs. expected heating rate of bed and chamber heaters has been widened, to avoid spurious heater faults on bed heaters with poor coupling between the thermistor and the thermal mass of the bed
The heater model now includes non-Newtonian cooling to better predict the variation of cooling rate with temperature and the maximum temperature that would be reached at continuous full power
The algorithm used to detect a heater fault while heating up now averages the heating rate over a longer period of time, so that noise in the reading is less likely to trigger a spurious heater fault
The generated resurrect.g file no longer includes a T-1 P0 command. This is to aid print recovery on tool changers.
Collecting more than 65535 accelerometer samples in a single run is now supported
When an accelerometer run is started, a check is made that the interrupt signal from the accelerometer is not stuck high
When using TMC2208/2209 drivers, the value of the chopper control register is now checked at frequent intervals against the value that should have been programmed
Build time comments in GCode files generates by REALvision slicer are now parsed
Handling of filament errors has changed - see the upgrade notes
Handling of driver stalls during printing has changed - see the upgrade notes
Heater faults during printing now cause macro heater-fault.g in the system folder to be run it if exist, with the heater number passed in param.D. If this file isn't found then the user is notified and the print is paused.
Heater faults that occur on expansion boards are now reported to the main board and treated in the same way as local heater faults.
Driver stalls, errors and warnings that occur on expansion boards are now reported to the main board and treated in the same way as local driver errors and warnings. System macro file driver-stall.g, driver-error.g or driver-warning.g (as appropriate) is run if it exists. The local driver number is passed as param.D, the CAN board address as param.B, the encoded driver status as param.P and the error or warning message as param.S.
When a M291 S2 or S3 command is executed in a macro initiated from PanelDue, RRF now notifies PanelDue if the message is cleared from another source, for example from DWC. PanelDueFirmware will need to be updated to clear the message box when it receives this notification.
After a tool change, the new tool is no longer moved to the position that the old tool was at when the tool change started (see the Upgrade Notes section).
G68 and G69 are implemented on an experimental basis when the selected plane is the XY plane. Use this with caution until more testing has been done.
If an attached magnetic filament monitor running version 4 firmware is unable to start because of a magnet problem, RRF now shows the error in the M591 response and M122 report
When stall detection endstops are used, the acceleration of any move for which a stall detection endstop is enabled is reduced
The reduced accelerations used by Z probing and stall homing moves can now be configured using command M201.1
M591 now reports whether all extruder movements or just printing moves are checked when using a Duet3D magnetic or laser filament monitor
The maximum depth for nesting macro calls and M120/M121 has been increased from 7 to 10
The PS_ON pin is no longer allocated as a power control pin by default. M80 and M81 now have an optional C parameter allowing the PS_ON port and polarity to be changed. See the upgrade notes.
When updating PanelDue firmware, the firmware file is checked to make sure that it is not too large
The unique IDs of CAN-connected expansion boards are now included in the object model, in their boards[] entries
When upgrading the main board firmware, if the IAP file is not found in /firmware then RRF looks for it in /sys
M39 now reports the partition size as well as the other SD card data
M98 with R parameter but no P parameter is supported, to control whether pausing is permitted while macros are executed
M955 when the accelerometer is connected to an expansion board now behaves the same as for accelerometers connected to the main board, i.e. it no longer reports the configuration when a configuration command completes successfully
In conditional GCode, the unary + operator can now be used to convert a value of type DateTime to a number of seconds from the datum.
In conditional GCode, function datetime(X) is added, to convert X (an integer, or a string with format yyyy-mm-ddThh:mm:ss) to type DateTime
M404 no longer supports the D (nozzle diameter) parameter because it was not used by anything
All main board firmware files now include a version string which can be found via the vector table. Previously this was implemented in expansion board and bootloader firmware only.
When switching out of laser mode using M451 or M453 the port assigned to control the laser is released automatically
M290 (babystepping) using relative mode is no longer permitted on an axis that has not been homed. Use of M290 to set absolute babystepping (e.g. to zero) is still permitted when the axis hasn't been homed.
M122 B# and M115 B# where # is the CAN address of a tool board now include the tool board hardware version to the extent that it is known
The ACT LED on the Duet3 Mini is supported
The option to append a read-only file system to the firmware binary an the end of the build process has been added
The H parameter of M0 is no longer supported. This means that if a print finishes with M0 and there is no stop.g file, all heaters will be turned off. Likewise, if a print is cancelled and there is no cancel.g file, all heaters will be turned off. Use a stop.g and/or cancel.g file if you want to leave heaters on.
M567 may now be used without a P parameter, in which case it defaults to the current tool
M569.7 (configure driver brake port) is supported, initially on the main board only
M955 with parameters other than P no longer returns the accelerometer details if the command was successful. M955 with just the P parameter still does.
echo >"filename" ... and echo >>"filename" ... are now supported
When a fan is configured as thermostatic using M106, the S parameter is now ignored. If a single T value is given, then when the temperature is above the T parameter the fan will run at the PWM specified by the X (maximum PWM) parameter (default 1.0).
The maximum number of fans supported on Duet 3 systems is now 20
A floating point expression can now be used where a driver ID is expected, provided that the value of the expression is close to a whole number plus a whole number of tenths
Array expressions are now supported in GCode parameters that expect multiple values, both in standalone and SBC modes using syntax { expression, expression, ... }. For example: M92 E{var.e1,var.e2}
Files with extension .nc are now assumed to be GCode files and parsed for all the usual parameters
Improved the speed of display refresh on 12864 displays with ST7567 controllers
LIS3DSH accelerometers are now supported in addition to LIS3DH (for accelerometers connected to SAMMYC21 boards, needs new SAMMYC21 firmware too)
The M956 command now accepts an optional F (filename) parameter
G10 L2 and G10 L20 commands now accept the P0 parameter, meaning use the current coordinate system (LinuxCNC extension)
Values of type DateTime can now be compared using equality and comparison operators
The F parameter of the M563 command can now be F-1 meaning there are no print cooling fans for this tool
New state "Cancelling" (meaning that the print has been cancelled and cancel.g is executing) is reported in the object model and displayed by DWC
Collection of accelerometer data is now supported in SBC mode
The first layer height of the file being printed is no longer reported in the object model or by M408
G- and M-codes with fractional parts in the code number can now be implemented using macro files. For example, if RRF received command M1134.1 then it will look for file M1134.g. This works even if the main code without fractional parts is already implemented by RRF; for example, you could provide file M114.1.g to implement code M114.1.
When creating a heater using M950 with H parameter, multiple output ports can now be used
M955 with just a P parameter now reports the SPI frequency if the accelerometer is connected via SPI
The M573 command is no longer supported. Use an echo command to display the value of heat.heaters[N].avgPwm instead.
If a G31 command specifies H and/or T parameters but they are not valid, the G31 command is no longer aborted and the remaining parameters are processed
M573 is no longer supported. You can read a heater average PWM from the object model instead.
M575 now supports the S5 parameter, which is like S1 but a CRC is required instead of a checksum, except that a checksum is accepted for M408 commands. This is to support forthcoming PanelDue firmware.
When homing fails, the axes that have not been homed are listed in the error message
Empty responses to GCode commands are no longer sent to PanelDue, as was the case before RRF 3.3
Maximum GCode command length when running in standalone mode or for input from USB or serial is increased from 200 to 255 characters
[Duet 3 Mini] Increased maximum extruders to 8
[Duet + SBC] Added automatic defragmentation of the SBC code ring buffer to improve support for concurrent G-code streams
[Duet + 12864 display] The rotary encoder driver now has improved immunity to noise
[Hangprinter Kinematics] Hangprinter support has been improved, in particular Hangprinter 4 is supported by the Duet 3 MB6HC board + EXP1XD boards, using the secondary CAN bus to configure the ODrives (thanks Torbjørn Ludvigsen)
[Duet 2] Increased maximum number of RGB NeoPixel LEDs from 60 to 80
[Duet 2] RRF now recognises whether an attached DueX board is version 0.11 or an earlier version. If version 0.11 then it shows that in the M115 response and adjusts the default M308 R parameter for thermistors and PT1000 sensors configured on ports E2TEMP to E6TEMP.
[Duet 2 SBC] The aux port is now configured for a PanelDue at 57600 baud by default so that automatic test equipment can test the board when there is no SBC connected
[Duet 3 Mini][Duet Maestro] The stepper drivers no longer default to stealthchop mode, because of the risk of excessive motor current if the correct tuning move is not executed
[Duet 3 Mini] The maximum number of bed and chamber heaters has been increased to 4 of each (previously was 2 of each)
[Duet 2 WiFi][Duet 3 Mini WiFi] Added support for additional ESP reset codes in preparation for new WiFi module code
[Duet 3 MB6HC in standalone mode] It is now possible to use the external SD card on an attached PanelDue, using a special wiring scheme
[Duet 3 MB6HC] The second CAN port is now configured and enabled. It uses plain CAN 2.0 protocol (not CAN-FD) and a default bit rate of 250kbps. It is provided primarily to facilitate configuration of external devices (e.g. ODrive) in forks or future versions of RRF.
[Duet 3 MB6XD] Support for the the Duet 3 MB6XD board has been added
[EXP1HCL] The EXP1HCL closed loop driver board is now supported
[Duet 3] Heaters, fans and filament monitors are now supported on these boards when they are switched into expansion mode using M954. Caution: this has not been tested thoroughly!
[Duet + SBC] Resume after power fail and resume after pause/power down are now supported
[Duet 3 with expansion/tool boards] When a motor connected to an expansion board is stopped by a probe or an endstop switch, any overshoot caused by CAN latency is now corrected. In particular this means that Z motors can be driven from expansion boards without the accuracy of bed probing being adversely affected.
[Duet 3 with expansion/tool boards] M122 for expansion boards now returns min, current and max values for VIN and (if supported) V12. As for the main board, each use of M122 resets the min and max values.
[Duet 3 with expansion/tool boards] Improved the reporting of clock jitter on CAN-connected expansion boards
[Duet 3 with expansion/tool boards] Implemented M569.2 for CAN-connected drives
[Duet 3 with expansion/tool boards] Expansion boards now track the temperatures of all sensors in the system. This means that a thermostatic fan connected to an expansion board can now be controlled by sensor(s) on different expansion boards(s).
[Duet 3 MB6HC] Maximum extruders per tool is increased to 10 and maximum heaters per tool to 20

Object model changes:

A new flag 'important' has been added to some object model fields, notably state.messageBox and the fields it contains. The "i" flag in the object model request flag indicates that these fields should be returned even if they would not normally be returned (for example because the "v" flag is also used) and that these fields should be return even when they have null values. The main purpose of this is to notify PanelDue of these fields when the Aux GCode channel is unable to make object model requests because it is executing a macro.
All boards[] objects now include the unique ID of the corresponding board if known. Previously, only the entry for the main board included the unique ID.
Field boards[].maxMotors is no longer flagged 'verbose'
Expansion boards now have separate firmwareVersion and firmwareDate properties in the boards[] object. Previously, firmwareVersion held both the version and the build date.
boards[].vin, boards[].v12 and boards[].mcuTemp for CAN-connected expansion boards are now populated if known and null if unknown
boards[].accelerometer is now added. It is null if there is no accelerometer connected to that board; otherwise it has fields "runs" and "points". "runs" is the number of runs commanded that completed or failed. "points" is the number of data points written to file when the last run completed, or usually 0 if the run failed.
Field fans[].frequency is added (the PWM frequency). This was already shown by DWC, however as RRF did not report the value DWC always displayed the default value of 250Hz.
For magnetic and laser filament monitors, field filamentMonitors[].configured.allMoves is added
[ATE mode only] Magnetic filament monitors now provide additional fields: agc mag position
[ATE mode only] Laser filament monitors now provide additional fields: brightness position shutter
Field heaters[].avgPwm is added
Field heaters[].model is no longer flagged 'verbose'
In heaters[].model fields gain, timeConstant and timeConstantFanOn are removed. Fields coolingRate, coolingExp and fanCoolingRate are added.
Field job.numLayers is added (zero if the total number of layers it not known)
Array job.thumbnails is added
Field job.file.firstLayerHeight is removed
The value of job.build.currentObject may now be greater than the length of the job.build.objects array. This is because the size of job.build.objects is limited to conserve memory (to 20 on Duet 2 or 40 on Duet 3), whereas when M486 labelling is used up to 64 objects can be numbered and individually cancelled.
Fields move.limitAxes and move.noMovesBeforeHoming are added
Fields move.shaping.amplitudes[] and move.shaping.durations[] are added
Fields move.rotation.angle and move.rotation.centre are added
Field move.kinematics.segmentation is added. It is null if the current kinematics is not using segmentation, else it has values segmentsPerSec and minSegmentlength.
Added fields percentCurrent and percentStstCurrent to move.axes[] and move.extruders[]
Added field canReverse to Spindle
Field state.deferredPowerDown is added. It is only available after power switching has been enabled by M80 or M81. When provided it normally has value 0 normally and 1 when a deferred power down is pending.
Field state.thisInput is added. It is not a property of the machine, rather returns the channel number of the input from which the request is received. This allows you to use expression 'inputs[thisInput]' within a macro to retrieve the current parameters (e.g. feed fate) of the GCode source that is executing the macro.
state.atxPower is no longer flagged 'live'. It is present if at least one M80 or M81 command has been executed and the PS_ON port is valid.
state.atxPowerPort is added, present under the same conditions as atxPower
state.macroRestarted is added. Its value is normally false, but when resuming a print that was paused while the file input stream was executing a macro, it is true at the start of the macro, until a regular G, M or T command (but not meta command) is executed. Therefore it can be tested at the start of a macro, to determine whether the macro was restarted after a pause or a power failure.
tools[].feedForward is added, giving the feedforward coefficient for each heater
Added field tools[].isRetracted to indicate whether a G10 firmware retraction command has been executed and not yet cancelled by G11
The Z offset of a Z probe is now reported as the negative of the trigger height instead of always being zero
Field volumes[].partitionSize has been added
Field boards[].name is populated for expansion boards (previously it was populated for the main board only)
The type of object model field state.deferredPowerDown is now Boolean (was previously integer)
Field fans[].sensors has been added
Field fans[].heaters has been flagged obsolete and will be removed in a future firmware version (use fans[].sensors instead)
[EXP1HCL] Field boards[].closedLoop with members 'runs' and 'points' is added for those boards that support closed loop control. It reports the number of data collection runs done and the number of point in the most recent run.

Internal changes:

FatFs has been upgraded from version 0.13c to 0.14b
When bed probing using G29, method IsReachable now sets the Z coordinate of the coordinates parameter to the probe starting height. Any other axes are set to the current coordinates. This is to aid kinematics classes for which IsReachable needs to know the Z coordinate, e.g. Hangprinter. Previously, the values of coordinates not included in the axes bitmap parameter was undefined.
DHT21 and DHT22 sensors now use less RAM
[Duet + SBC] Filament handling is now done by RRF, not by the SBC

Bug fixes:

M117 commands processed when the movement queue was not empty gave rise to "string too long" error messages
If the selected kinematics had both rotary and linear axes, and commanding movement of a rotary axes only required movement of a motor controlling a linear axis, then the feed rate calculation failed
If M591 P# S1 was used to enable a filament monitor after printing has already started, the filament monitor data was reset. This could lead to a spurious "no data received" filament error.
If the slicer uses the M486 command to label objects in the GCode file, and there were more than 20 (Duet 2) or 40 (Duet 3) objects, then RRF crashed when printing the file
If you homed any axes or changed tools when workplace coordinates are in use, then any absolute moves in the homing or tool change files had workplace coordinate offsets applied; whereas they should not
When M955 reported the configuration of an accelerometer that is connected to the main board using SPI, the orientation was always reported as 20 even if a different orientation had been selected by means of the M955 I parameter
The subtraction operator between two values of type DateTime errored out
When using the & operator in conditional GCode, if the first operand was false then an error might be reported and the macro aborted when parsing the second operand. Similarly if the first operand of | was true.
M106 proportional thermostatic control (i.e. using two T values) didn't work
M150 would hang if the LED type required bit-banging and the movement queue was not empty when it was executed
M505 did not report an error if the specified folder did not exist
M568 did not allow the P parameter to be omitted
The M584 command did not accept an array expression as a parameter value
M600 did not work in SBC mode
If a M956 command selected only some axes to collect accelerometer data for, and the orientation was not 20, then some collected axis data might be all zeros or from the wrong axis
Pressure advance was reported incorrectly in the object model
Detection of initial heating failure did not happen for heaters with slow heating rates
Under some conditions (most likely with a short movement queue length and many short moves) the movement queue would stall and the machine came to a standstill. When this happened, it could be restarted by pausing and resuming the print.
Local variables created within a job file were not cleared when the job completed or was cancelled
Unpredictable behaviour might occur when using a large number of mesh probe points (more than 416 points for most Duets)
When M572 was used to change pressure advance, DWC and DSF were not informed that this part of the object model had changed, so the object model displayed in the DWC object model browser showed the old value.
If GCode file generated by Superslicer had an estimated build time of a day or more, RRF parsed the build time comment incorrectly
Object model field move.kinematics.inverseMatrix contained values from the forward matrix instead of the inverse matrix
If you configured a "linear-analog" sensor with the F1 option on a port that does not support filtering then there was no warning and the computation of sensor reading was incorrect
If a macro file used a non-blocking M291 command and later used a blocking M291 command then the blocking message popup might be displayed first and then be overwritten by the non-blocking message popup
M574 with S3 parameter did not work correctly. All motors stopped as soon as one of them stalled (as for S2) instead of each motor continuing to move until stalled.
If the print was paused during a segmented move (including any G2 or G3 move) then when the print was resumed there was often a delay of many seconds before movement resumed
Fixed typo in message "the height map was loaded when the current Z=0 datum was not determined by probing"
The number of decimal places to which an expression was displayed in an echo command was sometimes lower than desirable if a division operation was involved in computing the value
G1 H2 moves involving only rotational axes did not always work
Short extruder movements caused magnetic, laser and pulsed filament monitors to report under-extrusion
Possible race conditions in the magnetic, laser and pulsed filament monitor code have been fixed. This may reduce the occurrence of spurious paused due to reported under or over extrusion.
DWC did not report the calibration figures for magnetic, laser and pulsed filament monitors
The extruder position reported in the object model and by DWC was always zero
In laser mode, the laser could be left turned on for up to 5ms after the end of a move
Z probe types 1,2,3 and 5 are only supported for Z probe 0 but no error message was generated if you tried to use one of these types for a Z probe other than probe 0
M669 for kinematics that are not usually segmented did not report the segmentation values if segmentation was enabled
Requests for ocsp-over-http were not recognised if the requested filename started with "ocsp" instead of "/ocsp"
M42 Jn C"nil" didn't release the port if it was on an expansion board
M106 without parameters reported the requested speed (last S parameter) when the fan was thermostatic, even though the S parameter is ignored for thermostatic fans
M500 now automatically saves the G31 parameters if they were previously loaded from config-override.g or saved using M500 P31
M906, M913 and M913 updated the object model but did not increment the corresponding sequence number. This meant that the corresponding values in DWC and DSF were sometimes out of date.
String parameters to macros were sometimes rendered invalid
The maximum number of filament lengths parsed from a GCode file when reporting file information was limited to the number of extruders, which didn't allow for having more mixing tools than extruders
The fields of move.compensation.meshDeviation in the object model were not updated when a height map is loaded
If a blocking M291 command was used within a homing file, on completion of that file homing was aborted with a "Homing failed" message. Any remaining un-homed axes were not homed.
An object model query for tools[N].fans[M] caused the firmware to terminate and reset
In the M122 report the per-driver data included a 'pos' value, however this was the position of the drivers for axis N instead of the position of driver N. This field has been removed.
If M929 was used to enable logging but the log file could not be created, no error message was generated
When M104, M568 or G10 was used to change the temperature of a tool when a different tool was active, under rare conditions the temperature change was not passed to the heater (it should be passed to the heater if the active tool does not use that heater)
When driver stall logging was enabled the stall messages reported to the console were not terminated with newline
In CNC and laser mode it is permitted to omit G0/G1 at the start of a line of GCode and just provide parameters, provided that the previous command was G0 or G1. However, only parameter letters that were present in that previous G0/G1 command were recognised.
[Hangprinter kinematics] When generating a resurrect.g file the M669 command was incomplete
[Polar Kinematics] When using Polar kinematics, XY movement was not permitted until Z had been homed
[Polar Kinematics] The code to limit speed and acceleration for polar kinematics didn't always work correctly
[Polar kinematics] M669 did not report the current A and F parameters
[Duet + SBC] Expressions such as "abs(move.calibration.initial.deviation - move.calibration.final.deviation) < 0.000" resulted in a "Expression nesting too deep" error
[Duet + SBC] Object model variables that represented a date and time, a processor unique ID or a port name could not be passed to DSF. One consequence of this is that they could not be used in echo commands, except as part of a larger expression.
[Duet + SBC] SBC file requests were not fully invalidated
[Duet 3 MB6HC] and [Duet 3 Mini Ethernet] File uploads over Ethernet sometimes failed with CRC errors
[Duet 2] If a TMC2660 driver was removed from the Duet or Duex then none of the TMC2660 drivers would start up
[Duet 3 in standalone mode] When generating default MAC address, the last byte of the processor unique ID was not used. This could lead to MAC address clashes when two boards from the same manufacturing batch were used on the same network.
[Duet 3 MB6HC] Using a with DotStar LED strip. If the brightness M150 P parameter (brightness) was not a multiple of 8 then the blue LED level was incorrect
[Duet 3 with expansion/tool boards] If some axes were driven using external drivers only, the main board could send moves too fast to the expansion board(s), which could eventually result in lost moves
[Duet 3 with expansion/tool boards] If a "stuck in spin loop" error occurred then RRF tried to turn off all heaters. This led to an assertion error if any of the configured heaters was connected to an expansion or tool board, so the details of the original error were not recorded in the software reset data.
[Duet 3 with expansion/tool boards] M569 and M569.1 did not wait for movement to stop when the P parameter was a remote driver
[Duet 3 with expansion/tool boards] In the object model the minimum values of VIN and V12 for expansion boards were always zero even if the board had been reset after power up
[Duet 3 expansion/tool boards] If a PT1000 sensor was configured but not connected, RRF reported a crazy temperature
[EXP3HC] The buffer used to store the sensor type name in a M308 command was too short to accommodate "thermocouple-max31855" or "thermocouple-max31856"
[Duet Maestro] The Zprobe MOD pin went low after approx. 45ms after startup. This confused an attached BLTouch which was starting up, causing it to go into error mode. This delay has been reduced to about 20ms.
[Duet] With PanelDue, if a macro file was initiated from PanelDue, and that file used a M291 S3 command followed later by a M291 S2 command followed later by another command that took some time to execute (e.g. another M291 S3 command) then the M291 S2 message was not displayed
[Duet 3 expansion/tool boards] If a Linear Analog sensor was configured on an expansion or tool board, the board crashed
[Duet 3] If M122 was run when the printer was halted, the machine reset and recorded a Hard Fault
[Duet 3 Mini][TOOL1LC] On a small number of systems it has been observed that a TMC2209 driver would occasionally increase motor current unexpectedly. We don't believe this was a software issue. However, the software now checks the chopper control register frequently; and if it is found to be wrong then the firmware corrects is and records a "cc" error. The count of these errors can be seen in the M122 diagnostics report for the driver.
[Duet 3] If the M150 command was used to control RGBW Neopixels connected to the dedicated output, and the F1 option was used to set different LEDs to different colours, then the colours were incorrect
[Duet 2 and DueX] If you used M591 to try to configure a laser or magnetic or pulse-generating sensor on a DueX endstop input or GPIO port then it should have failed with an "unsuitable pin" error, but this check was broken in firmware 3.3
[TOOL1LC] Temperature readings were inaccurate on some boards using 3.4.0beta7
[Duet + 12864 display] Adjusting the bed temperature using the live adjust facility did not turn the bed heater on
[Duet + SBC] When the SBC commanded the Duet to reset it did not turn off heaters or drivers and did not notify expansion boards. As a result the firmware did not have the correct expansion board data after restarting.
[Duet + SBC] M291 S3 could block an input channel when it didn't originate from a file and cancel was pressed
[Duet + SBC] Under rare circumstances, the updated code buffer space wasn't announced
[Duet + SBC] Message acknowledgment wasn't always working as intended
[EXP1HCL] Data capture is now supported even in open loop mode
[EXP1HCL] Failure to maintain the desired position is now reported to the main board
[EXP1HCL] Failure to maintain desire position is now reported even in open loop mode, provided that closed loop basic tuning has been done

RepRapFirmware 3.3

Known issues:

If the slicer uses the M486 command to label objects in the GCode file, and there are more than 20 (Duet 2) or 40 (Duet 3) objects, then RRF crashes when printing the file. This bug was also present in release 3.2.x.
If you home any axes when workplace coordinates are in use, then any absolute moves in the homing files have workplace coordinate offsets applied; whereas they should not. This is a new bug in release 3.3.
When M955 reports the configuration of an accelerometer that is connected to the main board using SPI, the orientation is always reported as 20 even if a different orientation has been selected (and is being used) by means of the M955 I parameter.
If a M117 command is executed when there are pending moves in the movement queue, a "string too long" error message is generated and the command is not executed. Workaround: use M400 immediately before M117.
When a line of received GCode includes a line number and checksum, RRF ignores a bad checksum
[Duet 3 with expansion/tool boards] If a sequence of short movements is commanded involving only motors connected to expansion boards, then the moves might be sent too quickly to the expansion boards, eventually resulting in lost moves.

Upgrade notes:

All extruders must be declared explicitly using M584. In previous firmware versions, one default extruder was assign to driver 3.
In previous versions, if a parameter letter should have been followed by a number but no digits were found, zero was assumed. Now RRF reports an error and abandons the command instead.
Firmware files are now stored in folder /firmware of the SD card instead of /sys
Unless you are running with an attached SBC, you must also upload the new Duetx_SDiap32_xxx.bin file for your board. Until you do, you will not be able to upgrade/downgrade from 3.3 firmware to other versions. The new IAP files have the same names as the previous IAP files for RRF3.2 and 3.2.2 and will also work with those versions of RRF.
Previously the command M106 R (with no P parameter and no value after R) would restore the last saved default print cooling fan speed, and if you did supply a value after R then that value was ignored. Now it is mandatory to specify a restore point number after R.
Fan speeds are no longer restored automatically when resuming a print. If you change the print cooling fan speed in pause.g, restore it in resume.g using M106 R1.
At the start of a tool change, the speeds of individual fans are no longer saved; however the speed of the default print cooling fan is saved in restore point 2. In the unlikely event that you need to save the speeds of individual fans before a tool change, you can retrieve the speeds from the object model and save them in variables.
The use of M106 with both P and R parameters is now deprecated and we plan to remove this facility in RRF 3.4. If you need to save/restore individual fan speeds, retrieve the speeds from the object model and save them in variables.
In preparation for for general input shaping in RRF 3.4, the M593 command now takes a P parameter to specify the input shaping type. Valid values in this release are "none" and "daa" or uppercase versions of those.
In the unlikely event that you have multiple Z probes and they all need the same non-empty deploy/retract sequence, you will need to create separate deployprobeN.g and retractprobeN.g for each probe, where N is the probe number. This is because only probe 0 now falls back to looking for deployprobe.g and retractprobe.g.
M675 can now only be used with a probe, not with an endstop (which didn't make much sense anyway). The K or P parameter must be provided.
M675 now uses parameter K for the probe number, in keeping with G29 and G30. Parameter P is still accepted as an alternative, for backwards compatibility.
M675 now calls the deploy and retract files for the selected probe
Previously, when M675 was executed the final position was saved in restore point 2, however this behaviour was not documented. The final position is no longer saved in a restore point. Use can use the G60 command after M675 if you want to save the position.
M585 now requires the F parameter to be provided
M585 now uses parameter K for the probe number, in keeping with G29 and G30. Parameter P is still accepted as an alternative, for backwards compatibility.
Previously, when M585 was executed the initial position was saved in restore point 2, however this behaviour was not documented. The initial position is no longer saved in a restore point.
Previously, when daemon.g was not found or after it had finished running, RRF paused for 1 second before trying to open it again. That time has been increased to 10 seconds to reduce the load on the SD card. If you need a daemon to execute more often than once every 10 seconds, use a loop inside the daemon.g file.
Spindle management and control has been fully rewritten and now resembles better what NIST GCode standard proposes. See M950, M563, M3, M4 and M5 description in GCode Documentation for details.
G31 Cnnn (temperature coefficient) parameter has been moved to G31 Tnnn to make C available as an axis (see new features below)
The object model for the height map (move.compensation.probeGrid) has changed
The object model for resonance compensation (move.daa) has moved
The height map file format has been extended. Height maps generated by earlier versions of RRF can still be loaded by this version, but height maps generated by this version of RRF cannot be loaded by earlier versions.
When changing tool, tool change files are now run regardless of whether axes have been homed or not. You can use conditional GCode to choose which commands are only executed if axes have been homed.
RepRapFirmware no longer tries to work out what layer number is printing, and no longer provides an estimate of print completion time based on layer progress. The mechanism to work out the layer number failed in many cases, for example when the slicer used variable layer heights or printed multiple objects one at a time. The removal of these 200 lines of hard-to-maintain code has made more space available for other features on the older Duets that are tight on memory space. A consequence of this change is that DWC will no longer produce a layer chart if the GCode file being printed does not include layer number comments. For slicers that do not normally generate these comments (e.g. PrusaSlicer) it is usually possible to add a layer change script to generate them.
[Duet 3 Mini] Immediately after upgrading to this release you may get spurious overheat warning messages for all the stepper drivers. If this happens, turn off VIN power to the Duet, wait a few seconds, and power on again.
[Duet 3 with expansion/tool boards] You must update the expansion and/or tool board firmware to 3.3 also, otherwise movement and some other functions will not work. If you accidentally end up with firmware 3.3 on a tool or expansion board and 3.2.x on the main board then the tool/expansion board will not achieve CAN sync with the main board; however it will still respond to some commands including M115, M122 and M997.
[EXP1XD] Previously, the step pulse width requested in the M569 command was rounded up to the next multiple of 1.33us. Now it is rounded up to the next multiple of 83ns. Additionally, the step pulse interval ands the hold time from the trailing edge of the step pulse to direction change are timed from the start of the step pulse, after adjusting for the width of the step pulse. The effect of these changes is that the step pulse width, step pulse interval, and step-to-direction hold time may not be rounded up as much as before; so M569 T values that used to work only because of the rounding up that occurred may no longer work.

New features:

When a "Bad command" error message is generated, any non-printing characters in the received command are shown in hex to make sure that they are visible
Fan RPMs down to 160 are now reported correctly (the previous lower limit was 320)
In the G38.2 command, parameter K can now be used to select the probe number
The CAN diagnostics in M122 reports have been greatly improved
When rehome.g is called because of motor stalls, for each axis for which a stall was detected, a parameter with value 1 is passed. This means that rehome.g can use tests such as "if exists(param.X)" to determine which axes need to be re-homed.
At the start of a print from SD card, the XY plane is selected for G2/G3 moves
G60 now saves the print cooling fan speed in the restore point
If M106 is used with a R parameter but no P parameter, the R parameter value is now the restore point number to get the speed from. Previously there was only one saved value for the default print cooling fan.
For filament monitor types 4 (magnetic + switch) and 6 (laser + switch), M591 with just the extruder number parameter now reports the filament present/not present status
M595 supports a new optional Q parameter to allow the configuration of the secondary movement queue to be changed
[Hangprinter Kinematics] M669 when using Hangprinter kinematics now allows the XY coordinates of the D anchor to be specified
[Hangprinter Kinematics] Hangprinter kinematics now supports line build-up compensation
The delay before trying to open the daemon.g file has been increased from 1 to 10 seconds, except for the first time. This reduces contention for the SD card.
The M122 report now includes the firmware date and time
The M122 report now shows the CPU utilisation per task. The reported figures will be inaccurate if more than approx. 90 minutes has elapsed since M122 was last run (or power on if M122 has not been run before).
New 'exists' function can be used to check whether a variable or parameter exists before using it
Accelerometers are supported, currently in standalone mode only (not in SBC mode). They can be connected directly to a main board via SPI, or connected to a SAMMYC21 via I2C.
RGBW NeoPixels LED strips are supported
[Duet 2] Bit-banged NeoPixel LED strips are supported on Duet 2 WiFi/Ethernet. On these boards RRF will wait stop movement while updating the LED strip, so M150 commands should not be issued while the machine is printing, other than at places where a short pause is acceptable such as at layer change and in the start and end scripts.
The maximum length of a NeoPixel strip is now 240 on Duet 3, 80 on Duet 3 Mini, and 60 on Duet 2
Tool offsets are now reported to 3 decimal places instead of 2 in G10 and in the object model
Object labelling in GCode files produced by Ideamaker are now recognised
Print time remaining comments in GCode files produced by Ideamaker are now recognised and processed like M73 commands
M25, M226 and M601 all accept a P0 parameter, which causes pause.g not to be run. M24 accepts a P0 parameter, which causes resume.g not to be run. Caution: in RRF 3.4 this is likely to be replaced by a P"filename" parameter.
Added M569.2 which allows any TMC22xx or TMC51xx stepper driver register to be read or written
A separate task is now used to finalise moves for execution
Data returned by TMC2209 drivers is now CRC checked
GCode meta commands now provide for creating local variables ('var' command) and global variables ('global' command), changing the values of variables('set' command), and parameters to macro files
M558 now accepts either one or two F values, e.g. F1000:300. If two values are provided, then when executing a G30 command with no P parameter an additional probe using the first speed will first be done to establish the approximate Z=0 position, followed by one or more probes (controlled by the A parameter) to establish Z=0 more precisely.
When using an analog Z probe, the probing speed is no longer reduced when the probe is close to triggering. Use the new M558 facility to do fast-then-slow probing instead, if necessary.
M568 has been repurposed as Set Tool Settings. It can be used to set tool offsets, tool temperatures and tool spindle RPM. G10 can still be used to set temperatures. M568 can also be used to switch tool heaters between off/standby/active without needing to select or deselect the tool.
M557 has been extended to allow defining a grid between an arbitrary axes pair, e.g. X-A and is no longer restricted to X-Y.
G31 has been extended to allow setting offsets for all axes (except Z)
M997 accepts a new parameter P"filename" to specify the filename to use for a firmware update. This can only be used when exactly one module is to be updated, i.e. it will not work with M997 S1:4
M669 S and T parameters are now supported on all kinematics. This allows segmentation to be used on Cartesian, CoreXY etc. and linear delta kinematics, for the purpose of allowing faster response to pause commands, M220 etc.
[Rotary Delta Kinematics]Auto calibration of rotary delta machines is supported experimentally
M486 now returns an error message if you try to cancel or resume an unknown object
Estimated print time provided by the slicer (using M73 commands if present) is now available. Estimated print completion time based on layer progress has been removed.
M408 and rr_status no longer report first layer duration or first layer height
Maximum step rates on all boards have been improved
Maximum length of expressions passed from DSF to RRF has been increased from 100 to 256 characters
When extracting file information, the support for Kiro Moto, Matter Control, Pathio, Fusion 360, IdeaMaker and SuperSlicer slicers has been improved
When executing G2 and G3 arc movement commands, the segments are finer than before
The maximum number of tracked objects has been increased, and space for the object names is now allocated dynamically
M17 is implemented
G17, G18 and G19 are now supported
Added M595 R parameter (thanks markmaker)
Increased the number of build plate objects tracked from 32 to 40 on Duet 3 and 3 Mini
[Duet 3 Mini] As an experiment, the MCU temperature sensor has been enabled. The manufacturer's errata document states that the sensor is not supported and should not be used; however it does appear to give useful readings, on some samples at least.
[Duet 2] When using extended step timings (M569 T parameter), maximum step pulse rates are improved a little
[Duet 3 Mini] M954 is partially implemented, allowing a Duet 3 MB6HC or Duet 3 Mini to be used as an expansion board. In this mode it can support axis motors, extruder motors (but extruders with nonzero pressure advance has not been tested), thermistor, PT100 and thermocouple temperature sensors, GpIn and GpOut pins (including hobby servos). Heaters, fans, filament monitors, endstop switches, Z probes and other types of temperature sensor are not yet supported.
[Duet 3 MB6HC] The maximum number of axes supported on Duet 3 MB6HC is increased to 15. Axis letters abcdefghijkl may be used in addition to XYZUVWABCD. Because GCode is normally case insensitive, these must be prefixed with a single quote character in GCode commands. For example, M584 'A1.2 would assign axis 'a' to driver 1.2, and G1 'A10 would move the 'a' axis to the 10mm or 10 degree position (or by 10mm or 10 degrees if in relative mode).
[Duet 3 expansion/tool boards] Heater tuning is now implemented (M303) along with heater feedforward
[Duet 3 with expansion/tool boards] Endstops and Z probes connected to the main board can now stop motors connected to expansion boards, removing the previous limitation. However, a small amount of undetected overshoot may occur when a homing or probing move is stopped. Until this is resolved in a future release, we advise against repeated probing (e.g for mesh bed compensation) when the Z motor(s) are connected to expansion boards, or measuring axis length using G1 H3 moves when the axis motor(s) concerned are connected to expansion boards.
[Duet 3 with expansion/tool boards] Improved the accuracy of CAN clock synchronisation between main and expansion boards
[EXP1XD] All step pulses generated by the EXP1XD now have exactly the same step high time as set by M569. The first M569 T value (step high time) will be rounded up to the next multiple of 0.0833us subject to a minimum of 0.25us (previously it was rounded up to the next multiple of 1.33us). The remaining T values will be rounded up to the next multiple of 1.33us as before. The fourth T value (direction hold time from trailing edge of step pulse) can now be negative, down to minus the step-high time.
[SAMMYC21] The sample firmware for SAMMYC21 now sends a diagnostic report to the USB port if character D is received from the USB port
[Duet + SBC] SBC interface diagnostics have been improved

Object model changes:

Restore points now have an additional field 'fanPwm'
[Hangprinter Kinematics]The object model for Hangprinter kinematics has changed. Fields anchorA, anchorB, anchorC and anchorDz have been replaced by a single 4-element array called anchor.
If you are using spindles[].active or spindles[].current they will no longer be negative for counter-clockwise RPM but additionally carry a new field spindle[].state that will have one of the three values stopped, forward or reverse and need to be interpreted together.
spindles[].tool has been replaced by tool[].spindle and reverses the assignment.
The height map object move.compensation.probeGrid has been changed to allow for axes other than X and Y
The resonance compensation object move.daa has been replaced by move.shaping to support more general input shaping. The members of move.shaping have not been finalised yet.
Added move.queue to object model, describing the main and (if present) aux movement queues
Added job.pauseDuration which is the total pause time since the job started
Added job.timesLeft.slicer
Added sensors[].probes[].speeds which is a 2-element array
Added global variables to the object model
job.warmUpDuration is now flagged live
job.layer is now only available if the GCode file being printed includes recognised layer number comments
The following object model fields are now flagged as obsolete and will generate a warning when used:
- sensors[].probes[].temperatureCoefficient (use temperatureCoefficients[0] instead)
- sensors[].probes[].speed (use sensors[].probes[].speeds[1] instead)
- move.compensation.probeGrid.(axis0, axis1, xMin, yMin, xMax, yMax, xSpacing, ySpacing) (use axes[], mins[], maxs[], spacings[] instead)
- move.workspaceNumber (use move.workplaceNumber - 1 instead)
- job.firstLayerDuration (it will always return null)
- job.timesLeft.layer (it will always return null)

Bug fixes:

If a tool heater was tuned using M303 with T parameter, and turning on the print cooling fan made no significant difference to the cooling rate, tuning would sometimes fail with a "bad curve fit" message
If a macro was aborted because a movement command failed, the error message was lost
It was not possible to use math operators with some unsigned object model fields e.g. job.filePosition and job.file.size
When a long-running command was initiated from PanelDue (e.g. mesh bed probing or delta auto calibration), "Bad command" and "Error parsing response" errors were sometimes reported on PanelDue
M595 with an out-of-range Q parameter would reset the machine due to an uncaught exception
M671 allowed up to 8 XY coordinates to be provided, but this should have been 4 (the maximum supported by the bed levelling algorithm)
M3 and M4 commands with both P and S parameters didn't work correctly
If pause.g, filament-change.g or filament-error.g used M291 to display a message and wait for a response, movement resumed until the response was provided
If a reset occurred because of an assertion failure, out-of-memory error or uncaught exception, then the task name in the software reset data in a subsequent M122 report was often corrupted depending on which task it was
Removed support for implicit G2/G3 commands because they is not part of the NIST GCode standard
Fixed M308 "string too long" message when configuring a thermocouple
Fixed memory protection fault or stack overflow crash when trying to pass macro parameters from DCS to RRF on Duet 3 MB6HC
[Polar Kinematics] [SCARA Kinematics] [Hangprinter Kinematics] When using polar, SCARA or Hangprinter kinematics the default segment length was not set up correctly, leading to the wrong size segments unless M669 was used with a T parameter
Added stack checks to recursive expression evaluation functions so that deeply nested expressions in user input abort gracefully instead of causing a reset
Using boards[n].shortName or boards[n].firmwareVersion in an echo command cleared any existing result string
[Hangprinter Kinematics]Hangprinter kinematics reported itself as SCARA
[Hangprinter Kinematics]Hangprinter kinematics needed segmentation for Z moves as well as XY moves, to maintain tension in all the cables
[Rotary Delta Kinematics]Rotary delta kinematics now uses segmented Z moves
M409 command now permits empty K and F parameters
If the pause.g file turned off the print cooling fan and deselected the tool (in either order) then the fan speed could not be restored in resume.g
Thermocouple sensors could not be configured because M308 didn't accept more than 20 characters in the sensor type name
When using a mixing extruder, if multiple E values were provided in a G0..G3 command but fewer than the number of extruders used by the current tool, the additional extrusion amounts were undefined
[Hangprinter Kinematics]The Hangprinter kinematics code sometimes attempted to take the square root of a negative number
M675 command did not work reliably (old bug)
M675 ignored any deploy and retract macro files for the probe (old bug)
M675 R parameter did not take account of the inches/mm setting (old bug)
M675 did not report errors if the probe was already triggered at the start of the probing move, or if the probe was not triggered by the end of the probing move (old bug)
M585 using a probe ignored any deploy and retract macro files for the probe (old bug)
M585 using a probe did not report errors if the probe was already triggered at the start of the probing move, or if the probe was not triggered by the end of the probing move (old bug)
Object model value 'seqs.inputs' was not incremented when various fields of object model array 'inputs' were changed, so DCS and DWC didn't keep the values up to date
Tool names were incorrectly converted to lowercase and had spaces removed
Retrieving 'tools[n].offsets[n]' from the object model failed with an error message
The 2-driver expansion board on a Duet Maestro or Duet 3 Mini used a separate channel to make it available as a pseudo temperature sensor, however that channel was not accessible. Those drivers are now included in the main channel.
The object directory state was not saved in resurrect.g because it was incorrectly written to config-override.g instead
G92 with an axis letter parameter also changed the accumulated extruder position reported by M114
DAA was often not applied where it should have been
When more than about 15 tools were configured, the object model fragment describing the tools was too long to send, causing DWC to disconnect
Job progress information was returned too infrequently when simulating
If a file was printed or simulated a second time, filament- and slicer-based print time estimates were not produced
Slicer-based time estimates were produced even when simulating a file
The original selected tool was not restored after simulating a file
Bed heater settings were not written to resurrect.g was if there was also an active chamber heater
When file resurrect.g was created due to a pause or power failure, settings for thermostatic fans were saved instead of settings for non-thermostatic fans
M500 did not persist the M307 Inn value and thus making inverted heaters non-inverted after M501
Pulsed filament monitors were active even when disabled by using S0 in the M591 command
Rarely, a height map generated by G29 S0 could not be loaded by G29 S1 due to rounding error
Most commands that took a pin name parameter did not accept an expression as the pin name
G4 with zero delay did not wait for movement to stop
G2/G3 commands with R parameter sometimes cause the job to abort
If a simulation was aborted due to an error, motion sometimes occurred
When waiting for a heater to reach temperature with M109 there were no more updates sent to PanelDue
It was not possible to delete a temperature sensor using M308 S# P"nil"
When a sensor was configured on a CAN expansion board and M308 was subsequently used to create a sensor with the same number on a different board, the old sensor was not deleted
[Duet 3 Mini] The stall detection sensitivity register was set incorrectly
[Duet 3 Mini] DHT sensors did not work. DHT sensors on the Duet 3 Mini now require both an output pin and an input pin. Note, support for DHT11 is likely to be removed soon.
[Duet + SBC] It was not possible to update PaneDue firmware using M997 S4
[Duet + 12864 display] The firmware would crash or behave unpredictably if in a 12864 display menu file an attempt was made to display an image at a position such that any row of the image was beyond the last row of the display
[Duet 2] Driver 11 connected to CONN_LCD did not work. It should now work provided that you have not configured a 12864 LCD.
[Duet 3 with expansion/tool boards] Laser, rotating magnet and pulsed filament sensors connected to expansion boards were active even when disabled by using S0 in the M591 command
[Duet 3 with expansion/tool boards] Under conditions of high movement density, a small number of motion commands might not be received by the expansion board
[Duet 3 expansion/tool boards] Under conditions of heavy load (e.g. a series of short moves at high step pulse rates), the board could stop responding to CAN commands and lose CAN sync
[Duet 3 with expansion/tool boards] The expansion board M122 report incorrectly recorded nonzero CAN 'bm' and 'wbm' error counts after executing G1 H1 or G1 H3 moves involving motors attached to expansion boards
[Duet 3 with expansion/tool boards] Fixed a race condition in the CAN driver that might result in delayed messages, or in rare cases loss of CAN communication
[Duet 3 Mini] When a low PWM frequency (e.g. 10Hz) was used on a heater, then movement was sometimes disrupted causing sudden jerks. Heaters connected to OUT0 and OUT2 suffered from this but OUT1 did not. Even lower PWM frequencies (e.g. 5Hz) disrupted SD card access too.
[Duet 3 Mini] M122 often reported communication timeouts with the TMC2209 drivers
[Duet 3 MB6HC] The DotStar LED driver did not work because the brightness was always set to zero
[Duet 3 Mini] 'state.atxPower' was always reported as 'false' in the object model after an M80 or M81 command
[Duet 2 and DueX] If in the M652 command the laser was configured to use a fan or GPIO port on the DueX, the firmware crashed when the laser was used. It is no longer permitted to configure a laser on these ports.
[Duet 2 WiFi] and [Duet 3 Mini WiFi] Using the C (channel number) parameter in M589 did not set the channel and caused loss of communication between the Duet and the WiFi module
[Duet 3 expansion/tool boards] When a tool/expansion board announced itself to the main board, it corrupted the sensors report message
[Duet 3 with expansion/tool boards] A M116 command at the start of a tpost#.g file might not wait for a tool heater connected to an expansion or tool board to reach temperature if the tool heater was off before the tool was selected
[Duet 3 with expansion/tool boards] Spurious CAN transmit timeouts were reported by main boards in the M122 report
[Duet 3 expansion/tool boards] The free system stack was always reported as zero
[Duet 3 expansion/tool boards] Occasionally the red status LED would briefly flash rapidly indicating loss of CAN sync, when in fact sync had not been lost
[Duet 3 with expansion/tool boards] When a motor on an expansion board was commanded to move when not already enabled, and other commands were being sent to expansion boards concurrently, "Discarded message" warnings were sometimes generated
[Duet 3 with expansion/tool boards] An expansion or tool board would very occasionally reset without warning because of a race condition. The software reset data in the M122 report for that board reported an assertion failure.
[Duet 3 MB6HC + expansion/tool boards] There was excessive clock jitter on expansion/tool boards because the CAN timestamp counter in the MB6HC MCU does not always operate in accordance with the manufacturer's documentation
[Duet + SBC] RRF updated job.lastFileName as soon as the print started. RRF no longer reports job.lastFileName while a print is in progress.
[Duet + SBC] The SBC task stack might overflow when a 'set' command was received from the SBC and executed

RepRapFirmware 3.2.2

Upgrade notes: none since 3.2

Bug fixes:

Using an external SD card could result in the firmware crashing if there was concurrent access to the Duet from DWC or another network client. [This is an old bug, however changes in firmware 3.1 and later made it much more likely to happen.]
If two DueX endstop inputs changed state approximately 2.2ms from each other, the second one might not be detected by the firmware. [This was a regression in 3.2]
The pin name string in M574 commands was truncated to 50 characters if it was longer, which was too short to allow four DueX endstop pins to be used. This has now been increased to 100 characters.
The M109 command caused a "Homing failed" message if it was used in a homing file and that homing file also called another macro file
In GCode expressions it was not possible to compare a value with character type (e.g. move.axes[nn].letter) with a string literal
Spurious blank lines were sometimes sent to USB and Telnet clients when the daemon.g file was used
If a G2 or G3 command with R parameter described an arc of exactly 180 degrees, then due to rounding error RRF might report "G2/G3: invalid combination of parameters".
Implemented a partial fix for G2/G3 moves on IDEX machines
[Duet 3 Mini] It was not possible to write to an external SD card
[Duet + SBC] Expressions were not supported in GCode parameters that accept an array of values. Expressions are now supported when only a single element needs to be provided.
[Duet 3 with expansion/tool boards] If DAA (M593) was used then motors connected to expansion or tool boards might lose steps
[Duet 3 with expansion/tool boards] The M591 E parameter was ignored for filament monitors connected to expansion or tool boards
[Duet 3 MB6HC] (regression in 3.2) DHT sensors did not work
[Duet 3 MB6HC] (regression in 3.2) The minimum step pulse width time of the TMC5160 was not always met. This could lead to missed steps when high step rates were used.

RepRapFirmware 3.2

Upgrade notes (see also Object Model Changes if you use conditional GCode):

Default thermistor parameters for all builds of RRF3 are now: T100000 B4725 C7.06e-8. These match the thermistor used by E3D better than the old default, which had B4388 C0. In the unlikely event that your M308 line had a C parameter but no B parameter, you will need to add B4388 to get the previous behaviour.
If you are using object model field move.workspaceNumber in conditional GCode, you should preferably replace it by (move.workplaceNumber + 1). Note the different name, and that the new workplaceNumber is 0-based (so it can be used to index the workplaceOffsets arrays directly) whereas workspaceNumber was 1-based. We plan to remove workspaceNumber in a future release.
If you are using the M453 command to configure spindle motors and switch the firmware into CNC mode, you will need to change this command because the parameters have changed.
If you configure a Z probe using multiple M558 commands instead of a single one, you must make sure that only the first one has a P parameter. This is because M558 with a P parameter now sets default values before processing the other parameters of the M558 command.
In GCode commands, numeric parameters of the form "0xdddd" where dddd are hex digits are no longer supported. Use {0xdddd} instead.
It is no longer permitted to create a filament monitor using M591 and subsequently to use M584 to change the driver that the extruder is mapped to
The IAP files for this release have changed. After installing 3.2, the new IAP file will be needed next time you upgrade or downgrade the firmware. The new IAP files all have 'iap32' in the filename where it used to be 'iap', therefore they can coexist in /sys with the old IAP files.
The M303 heater tuning algorithm and parameters have changed. See https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m303-run-heater-tuning.
The M307 heater model parameters have changed, however existing M307 commands will continue to work. See https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m307-set-or-report-heating-process-parameters
When new axes are created using M584, if no R parameter is specified then the default for axes ABCD is now rotational. Use the R0 parameter if you want them to be linear.
[DWC] If you are running DWC in a development environment (e.g. via 'npm run serve'), use M586 C"*" or similar to permit cross-origin HTTP access or similar to permit cross-origin HTTP access
[Duet + SBC] The SPI protocol has changed, therefore versions of DCS prior to 3.2RC1 will be unable to communicate with RRF 3.2
[Duet 3 with expansion/tool boards] You must update the expansion and/or tool board firmware to version 3.2 also
[Duet 3 MB6HC] if using an attached DotStar LED strip then you now need to use M150 with the X parameter to specify the LED strip type. This is because the default type is now Neopixel.

Known issues:

[Duet + SBC + 12864 display] Menu files are slow to load
[Duet 3 with expansion/tool boards] A small number of EXP3HC expansion boards and even fewer TOOL1LC boards take a long time to start up after power up when running 3.2 firmware. The most common symptom is that some of the configuration commands for them in config.g fail. In rare cases, the status light may remain off for some time before it starts flashing to indicate CAN sync (slow flash) or lack of sync (fast flash). As a workaround until we produce a fix that works in all cases, we recommend (1) use a G4 S1 delay command in config.g before the first command that refers to a motor or port on any expansion board, and (2) if in any doubt, run M98 P"config.g" from the console after power up and check there are no error messages.
[Duet 3 with expansion/tool boards] If you use DAA (M593 command) and you have any extruders connected to expansion boards then steps may be lost on the motors connected to those expansion boards. This issue is also present in previous firmware revisions and is fixed in 3.3beta firmware.
[Duet 3 with expansion/tool boards] When high step rates are demanded from motors connected to expansion and tool boards, the motors may get out of sync with the main board. This issue is also present in previous firmware revisions and is fixed in 3.3beta firmware.
[Duet 3 with expansion/tool boards] If a laser, magnetic or pulsed filament monitor is connected to an expansion or tool board, then any E parameter in the M591 command to configure it is ignored. Fixed in 3.3beta firmware.

New features:

A default filename is no longer provided in the M559 and M560 commands, so the P parameter must always be used
Added L (calibration factor) parameter to laser filament monitor configuration
Added M584 R parameter to indicate whether newly created axes are continuous rotation axes or not
Added aux port diagnostics (overrun and framing errors) to M122 report
Any attempt to use G28 within a homing file now results in a specific error message
CORS headers are only sent in HTTP responses if explicitly configured via M586. The M586 command now accepts a C parameter to specify the allowed cross-origin site.
Default thermistor parameters for all builds of RRF3 are now T100000 B4725 C7.06e-8. These match the thermistor used by E3D better than the old defaults.
Drivers number of the form 0.# where # represents one or more decimal digits are now supported even on board that don't support CAN
Duet 3 Mini 5+ WiFi and Ethernet boards are supported (PCB revisions 0.4 and later)
G29 with no S parameter now runs file sys/mesh.g if it exists; otherwise it behaves like G29 S0 as before
If a filament error occurs, RepRapFirmware now tries to run file sys/filament-error#.g where # is the extruder number in minimum-width format; or if that file is not found then file sys/filament-error.g. If neither file is found then it falls back to running sys/pause.g.
If a filament monitor is configured for an extruder, and subsequently M584 is used to assign that extruder to a different driver, then the filament monitor will be deleted automatically and a warning issued
If a tool change is requested but changing tool would cause the Z max limit to be exceeded because of the changed tool Z offset, the tool change is now aborted
If the system runs out of memory, it will now reset and the Last Software Reset Reason reported by M122 will be "OutOfMemory"
Improved the instructions displayed when M303 heater tuning finishes
Increased the number of stack words displayed in the software reset data. The number of wear-levelling slots stored is reduced from 4 to 3.
It is no longer necessary to separate multiple G- or M-commands on a single line with a space or tab character
M111 supports CAN module debug
M118 has a new Lnnn parameter to specify at which log level the message will be logged (default: DEBUG). Using L0 will prevent a message being copied to the log file.
M122 for expansion and tool boards now reports the bootloader version, if available
M150 commands are now queued to sync them with movement commands
M308 S# H999 and L999 are now supported on those Duet 3 expansion/tool boards that have the required hardware support
M453 and M452 no longer report the new machine mode. Use M450 after these commands if you want the machine mode to be reported.
M486 now confirms when an object is cancelled or resumed
M558 with a P parameter now always creates a new Z probe object, which means that all the other M558 values are set to default values before processing the other M558 parameters
M571 command accepts Q as an alternative to F for the PWM frequency
M581 trigger condition parameter now supports a new value R2 which means trigger only if not printing from SD card
M584 commands are now checked for out-of-range driver numbers
M584 has a new S parameter which specifies whether new axes created in the command are to be treated as linear (S0) or rotational (S1) for the purpose of feedrate calculation. This is separate from the R parameter, which specifies whether new axes are rotational or not. The default is to treat linear axes as linear and rotational axes as rotational. You only need to provide the S parameter if you want to change the way that the feed rate is applied.
M591 may now be used to delete a filament monitor using the syntax M591 D# P0 where # is the extruder number
M906, M913 and M918 commands now wait for movement to stop, except when they are used in the power fail script
M929 now uses the S parameter to specify a logging level: 0=off (as previously no logging), 1=warn (all previous logged messages are in this category), 2=info (M117, M291, M292 and G10 fall into this category), 3=debug (everything else that generates output)
New M595 command is provided to allow the movement queue to be lengthened and optionally to pre-allocate DriveMovement objects
Numeric literals in GCode meta commands and in expressions enclosed by { } can now be in hex (0x prefix) or binary (0b prefix)
Previously there was a minimum reading cutoff at -5C when measuring temperatures using any kind of thermistor. That cutoff is now relaxed when using a low-resistance thermistor, e.g. with resistance 1K or 10K @25C.
Support for connecting the Ethernet adapter socket of Duet Ethernet to SBC instead, using a separate firmware build
[Duet Maestro] Support for ST7567-based 12864 displays on Duet Maestro and Duet WiFi (thanks to SchmartMaker for writing the ST7567 driver code)
[Duet 2]Support for ST7920-based 12864 displays on Duet 2 WiFi/Ethernet
Supports PanelDue 3.2 better, in particular updating of displayed data while waiting for heating etc.
The M122 P102 and M122 P103 timing functions are more accurate and give more consistent results than in previous firmware versions
The M203 command now supports an optional S1 parameter which changes the units to mm/sec. The default is still mm/min.
[Duet 2] The amount of free RAM has been increased. This should be sufficient to allow 12864 displays to be supported on Duet 2 WiFi/Ethernet.
The minimum value for the P parameter of M584 is reduced from 3 to 2 so that the Z axis can be hidden
The number of DriveMovement objects pre-allocated is reduced to save memory. If the system runs out of DriveMovement objects, it will try to allocate new ones dynamically.
The order in which you use M307, M140, M141 and M143 is now immaterial
The parameters for M453 have changed. The frequency parameter is now Q (to match M950) instead of F. You can configure up to 3 ports to control each spindle. See https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m453-select-cnc-device-mode.
The resurrect.g file now records which objects on the build plate have been cancelled
The speed of processing of GCodes received from USB has been improved, to match the speed of processing GCodes read from the SD card
Version 3 PanelDue boards (including all PanelDue 5i/7i) can now be updated from the Duet using M997 S4
When an unexpected software reset occurs, a stack usage check is performed and the result added to the software reset data
When new axes are created using M584, if no R parameter is specified then the default for axes ABCD is now rotational. Use the R0 parameter if you want them to be linear.
WiFi diagnostics now include the WiFi connection mode (needs DuetWiFiServer 1.25beta0)
Z probe trigger height second order temperature compensation is now supported. To use it, specify a 2-element array as the temperature coefficient, e.g. "M558 ... C0.01:0.0005".
[Duet + SBC] 12864 displays are now supported. Note, the 'files' menu item type is not supported in SBC mode.
[Duet + SBC] RepRapFirmware no longer goes into SBC mode if a SD card is inserted but can't be mounted, or if config.g is not found. This is to make diagnosis of SD card interface faults easier.
[Duet 2 Ethernet/WiFi/Maestro] Duet 2 builds now permit port names to have a "0." prefix, e.g. "0.e0heat". The "0." prefix is ignored.
[Duet 3 with expansion/tool boards] Expansion and tool boards can now have their bootloaders updated via CAN using the command M997 B# S3 where # is the board address. The bootloader file is Duet3Bootloader-SAME5x.bin for the EXP3HC board, Duet3Bootloader-SAMC21.bin for the other expansion boards by Duet3D, and Duet3Bootloader-SAMMYC21.bin for the Sammy-C21 development board. These files are available at https://github.com/Duet3D/Duet3Bootloader/releases.
[Duet 3 with expansion/tool boards] Filament monitors are now supported on Duet 3 expansion and tool boards. A filament monitor must be connected to the board that drives the extruder that it monitors.
[Duet 3 expansion/tool boards] Added M122 P102, P1005 and P1006 functions
[Duet 3 expansion/tool boards] Increased performance, in particular the maximum step rate is higher than before
[Duet 3 expansion/tool boards] Software reset data is now stored in NVRAM and reported by M122
[Duet 3 tool boards] Stepper driver diagnostics now include the PWM_AUTO register (main board diagnostics did already)
[Duet 3] Added support for second UART (using the IO_1 pins) on Duet 3 MB6HC. New message type (P5) added to M118 command.
[Duet 3] CAN diagnostics on both main and tool/expansion boards provide more data
[Duet 3] Default LED strip type is now Neopixel not DotStar
[Duet 3] M915 with just P and/or axis parameters now reports the belt speed in mm/sec that corresponds to the coolStep threshold
[Duet 3] Z probing is now abandoned if the probe is remote and cannot be contacted
[Duet Maestro and Duet 3] Added M308 S# H999 for open-circuit thermistor input calibration, and M308 S# L999 for short-circuit calibration. The calibration values are stored in non-volatile memory. See https://docs.duet3d.com/en/User_manual/Connecting_hardware/Temperature_connecting_thermistors_PT1000#temperature-calibration-and-adc-tuning.
[Duet Maestro] M308 L and H parameters are now supported.
[Duet] With PanelDue, status messages are sent to an attached PanelDue running firmware 3.2 during homing, heating tools etc.

Object model changes:

Added calibrationFactor to the laser filament monitor object model
Added lastStopHeight to the Z probe object model
Added minRpm to the spindle object model
Added move.workplaceNumber to the object model. This is intended to replace move.workspaceNumber, but is 0-based instead of 1-based.
Added random(nn) function
Added state.msUpTime. This is the milliseconds part of upTime. When using the HTTP rr_model call or the M409 command, if the response includes both state.upTime and state.msUpTime then these two values both relate to the same instant when the command started searching the object model.
Added temperatureCoefficients array to the Z probe object model. For backwards compatibility, temperatureCoefficient is still supported for the time being and is equivalent to temperatureCoefficients[0]. We plan to remove temperatureCoefficient in a future release.
All types of filament monitors have a new field "status". The value is one of "noMonitor", "ok", "noDataReceived", "noFilament", "tooLittleMovement", "tooMuchMovement", "sensorError".
Field "filamentPresent" is removed from those types of filament monitor that previously supported it. Use "status" instead.
Field "move.axes[].homed" is no longer flagged live, and it now remains the true homed status during a simulation
Field "supports12864" in boards[0] has been renamed to "supportsDirectDisplay"
Laser, rotating magnet and pulsed filament still support the "calibrated" fields, but only for filament monitors connected to the main board
Spindle current/configured/max RPM were being output to 7 decimal places in object model queries. Now they are reported as integers.
Support DateTime - DateTime, DateTime + int, DateTime - int
Support T{expression} commands
Support comparing a value of any type that has no literals (DateTime, IPAddress, MAC address, DriverID) with a string
Variable boards[n] for expansion boards now includes the maxMotors value

Bug fixes:

A M591 command with the C parameter not followed by a port name string caused the firmware to reset
A layer change was detected incorrectly if a travel move at an unusual height included retraction
After updating PanelDue firmware with M997 S4 the PanelDue did not always reset automatically
At the very end of a print job, RRF sometimes briefly reported a bad file position, which caused DWC to report a very high % completed
Duet 3 Mini only: certain types of error accessing the SD card would cause the firmware to reset due to "Stuck in spin loop".
Feed rate calculations did not confirm to the NIST standard when the Z axis and one or more rotational axes were moving, but not X or Y. This affected CNC machines with rotational axes, and OpenPnP.
Fixed a buffer overflow when the number of filaments reported by PrusaSlic3r exceeds the maximum number of supported extruders
Fixed bug in GetProportionDone that might have caused an incorrect extrusion amount for the first move after restarting a print following a power failure
Fixed crash that occurred on some systems when M918 was used to configure a 12864 display but no SD card was present
Fixed issue with G29 S1 on Duet 3 with attached SBC causing the print to fail if any if the probe points had been unreachable when the height map was probed
G2 and G3 commands with R parameter always drew the longer of the two possible arcs. Now they draw the shorter one if the R parameter is positive, or the longer one if it is negative.
G92 Znn didn't clear zDatumSetByProbing
G92 commands incremented seqs.move when they didn't need to
If M918 was run multiple times, available RAM was lost because of a memory leak
If M997 S4 was used but no aux port was configured, the firmware could reset after 20 seconds
If a G31 command defined new values in terms of existing G31 values from the object model, then incorrect values could be set due to the new values being computed and stored multiple times
If a TMC22xx driver received two commands to enable/disable the drive or change microstepping twice in very quick succession, the second one was sometimes lost
If bed compensation taper (M376) was used, bed compensation was not applied correctly if the tool had a Z offset
In M122 reports, queued GCodes were printed with spurious characters after each command
In Marlin mode, "ok" was returned per-command instead of per line of GCode
In RepRapFirmware mode, empty responses to commands were not suppressed. They are now suppressed except when the command came from HTTP or SBC.
Incorrect M307 default parameters were used for bed and chamber heaters
Laser and magnetic filament monitors paused the print even when disabled if no data was received or the sensor reported an error
Loading IAP during a firmware upgrade might fail on Duet 2 if a filament monitor or fan tacho was active
M118 P0 didn't append newline when the message was sent to USB and Telnet
M669 K5 reported that the kinematics matrix was invalid
M918 P0 reported an error instead of just deleting any existing display
Object model variable seqs.spindles was not updated when the configuredRpm of a spindle was changed
PanelDue was not updated while the firmware was waiting for a heating or delay command to complete
Some types of underrun in the movement queue were not reported
The Error Status word was incorrectly prefixed by 0x02 in beta1 instead of just 0x
The M409 response didn't end in newline and was invalid JSON if RRF ran out of output buffers. Now RRF returns {"err":-1} if it runs out of buffers, and the response is always terminated by newline to help clients recover from errors.
The PWM frequency for heaters was supposed to be limited to 1KHz but this check was no longer being performed
The handling of out-of-buffer situations when generating HTP responses has been improved. Where a JSON response was expected, RRF will generally now return {"err":-1} if there was insufficient buffer space to satisfy the request.
The output from M207 without parameters was truncated when there were 4 or more tools
When a GCode file included very short moves, sometimes the print paused for a time (sometimes a very long time) at that point
When doing a simple G30 command the the probe type was BLTouch, the deploy and retract macro files were each run twice
When the machine was executing resume.g, the 'resuming' status was not reported in the object model
[Duet + SBC] Fixed several issues with communication between the Duet and the SBC
[Duet + SBC] The height map parameters passed by the SBC were not range-checked
[Duet + SBC] When file daemon.g was requested, spurious warning messages could be displayed
[Duet 3 with expansion/tool boards] The idle timeout was not always applied to remote drives, in particular to extruder drives
[Duet 3 MB6HC + expansion/tool boards] Sometimes the main board would not receive status messages from expansion and tool boards after power up unless it was reset by M999 or emergency stop
[Duet 3 MB6HC] A watchdog timeout didn't save any software reset data
[Duet 3 MB6HC] Fixed an issue that very occasionally caused a MemoryProtectionFault from the Ethernet task
[Duet 3 MB6HC] The second aux port using the IO_1 connector did not work
[Duet 3 expansion/tool boards] Thermostatic fans connected to expansion/tool boards would occasionally blip spuriously
[Duet 3 with attached SBC] When an array parameter (e.g. M92 E value) had more than one element but less than the maximum number, the last element was replicated to fill the array. This was inconsistent with non-SBC behaviour, which only pads the array when a single element is provided.
[Duet 3] DHCP requests were being made made much too often when the DHCP lease time was long e.g. 1 hour or more
[Duet 3] Fixed a bug that caused strange behaviour during homing in some configurations when axis motors were connected to expansion boards
[Duet 3] M915 with just P and/or axis parameters did not report the coolStep threshold (T parameter) correctly
[Duet 3] When using a LinearAnalog sensor, the readings returned were too high above the minimum reading by a factor of 4
[Duet 3 Mini] and[EXP3HC] Fixed missing cache invalidate after receiving a CAN message
[Duet + SBC] When attached to a SBC, M29 commands received locally are now sent to the SBC for processing
[Duet + SBC] A buffer overflow might occur in the SBC interface code under conditions of heavy traffic
[Duet + SBC] When nested macros were used, commands were sometimes executed out-of-order
[LPC/STM port, might affect Duets in rare situations] If hiccups occurred frequently and there was other activity in the system causing frequent high-priority interrupts, a watchdog timeout could occur

Other improvements and changes:

Calls to debugPrintf use less stack than before
Efficiency improvements to TMC2208/2209/2224 drivers for both main and tool boards
Substantial performance improvements and much higher maximum step rates on Duet 3 MB6HC, EXP3HC and TOOL1LC boards
In the M122 report, unused stack for each task is now reported in dwords, not bytes
[Duet 3] CAN diagnostics have been improved

RepRapFirmware 3.1.1

Recommended compatible firmware:

DuetWebControl 3.1.1
DuetWiFiServer 1.23 (same as for previous RC)
Duet Software Framework version 3.1.1 (for Duet 3/Raspberry Pi users)
Duet 3 expansion board and tool board firmware 3.1.0
PanelDueFirmware 1.24

Upgrade notes:

Available RAM is slightly reduced in this version. This won't affect most users, however if you are running a Duet WiFi or Duet Ethernet with a large number of tools/heaters/sensors etc. then check that the Never Used RAM in the M122 report is comfortably above zero.
If you are upgrading from a version earlier than 3.1.0, see also the upgrade notes for version 3.1.0.

New features/changed behaviour:

Maximum GCode line length is increased from 160 to 200 characters
The number of decimal places reported for axis minimum and maximum limits from the object model is increased from 1 to 2
Duet 3: M122 now says whether the Duet is running in SBC or standalone mode
Added object model field 'state.time'. This will be null if the date/time hasn't been set, otherwise a string in ISO format such as 2020-05-10T07:59:31.
Object model variables which represent a date and time (e.g. file last modified time) are now in ISO format, i.e. "2020-05-10T07:59:31" instead of "2020-05-10 07:59:31". This is for compatibility with DSF and with the way they are returned by M409.

Bug fixes:

In some configurations the firmware crashed occasionally because the NETWORK task stack overflowed
Changes to Z probe parameters made by G31, M558 and M851 were not reported to DCS or DWC
Duet 3 with SBC: G29 (optionally with S1 parameter) rewrote the old height map to the virtual SD card instead of writing the new one
Duet 3 with SBC: certain commands completed in the wrong order
G92 commands did not updated seqs.move

RepRapFirmware 3.1.0

Recommended compatible firmware:

DuetWebControl 3.1.0
DuetWiFiServer 1.23 (same as for previous RC)
Duet Software Framework version 3.1.0 (for Duet 3/Raspberry Pi users)
Duet 3 expansion board and tool board firmware 3.1.0
PanelDueFirmware 1.24

Upgrade notes:

If you are upgrading from RepRapFirmware 2.x then you will need to make substantial changes to your config.g file. See https://docs.duet3d.com/en/User_manual/RepRapFirmware/Migration_RRF2_to_RRF3 for details. Also you must upgrade to the 3.0 release first.
All PanelDue users: the PanelDue connector (or IO_0 on Duet 3) is no longer dedicated to PanelDue, therefore if you connect a PanelDue to this port you must use the following command in config.g to enable it: M575 P1 S1 B57600. You can use baud rates other than 57600, however the IAP files all assume 57600 baud; therefore if you use another baud rate then PanelDue will not display firmware update progress.
If you use M581 commands you must replace the C parameter by R
Tool change files are now run even if the axes have not been homed. If you don't want certain parts to run when axes have not been homed, use conditional GCode in the tool change file.
After a tool change, the user Z coordinate is restored immediately instead of by the end of the next G0 or G1 command.
Duet WiFi, Ethernet and Maestro: a default bed heater is no longer assigned, so you need to use M140 H0 in config.g if you want to replicate the previous behaviour. The online configurator already generates this command automatically when you configure a bed heater. Any M143 H0 command must come later in config.g than the M140 H0 command, because M140 resets the temperature limit for the heater to the default for bed heaters.
The I (invert) parameter of M558 has been removed. If you were using I1 then you will need to invert the pin name instead.
Legacy 5-point bed compensation is no longer supported
The tool number (P parameter) in a M563 command must now be in the range 0-49
Duet 3: If you were using M308 H or L parameters for thermistors attached to a Duet 3 main board, you will need to adjust those values
The parameters to M577 have changed. See https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m577-wait-until-endstop-is-triggered.
The parameters to M581 have changed. See https://docs.duet3d.com/User_manual/Reference/Gcodes#m581-configure-external-trigger.
The P parameter to M143 now has a different meaning. Also the X (sensor) parameter has been replaced by T. See https://docs.duet3d.com/User_manual/Reference/Gcodes#m143-maximum-heater-temperature.

Known issues and limitations:

If you execute a tool change at a Z value close to maximum then this could result in at attempt to exceed maximum Z depending on the difference between the old and new Z tool offsets.
Z probe types 1, 2 and 5 are only supported for Z probe 0, and if using Duet 3 only for a probe connected to the main board. All other Z probes must be of type 8 or 9.
Duet 3: an endstop switch or Z probe connected to the main board will not stop movement of a motor on an expansion board unless a motor on the main board is also moving
Duet 3: when updating the firmware on one or more tool boards or expansion boards, after the updates have completed you must reset the main board or at least run config.g in order to reconfigure the expansion or tool boards
Duet 3: additional limitations apply to systems with expansion and/or tool boards. See https://docs.duet3d.com/en/User_manual/RepRapFirmware/CAN_limitations.

New features:

The if, elif, else, while, break, continue, echo and abort GCode meta commands are implemented, along with expression evaluation. See https://docs.duet3d.com/en/User_manual/Reference/Gcode_meta_commands.
The RepRapFirmware Object Model has been implemented. See hhttps://github.com/Duet3D/RepRapFirmware/wiki/Object-Model-Documentation.
M409 and a corresponding HTTP call rr_model have been added, to allow parts of the object model to be queried
The parameters to G- and M-commands can now be expressions and can use values retrieved from the object model
M486 object cancellation is now implemented. Object labels are read from comments in the file if provided. When printing from SD card the object model includes subtree "job.build" to describe the known objects, so that a future version of Duet Web Control will be able to offer an object cancellation interface. Caution: although the code has been designed to handle multi-tool machines, it has not yet been tested with prints that use more than one tool.
The PanelDue connector (or IO_0 on Duet 3) is no longer dedicated to PanelDue. When not used for PanelDue, its two pins are available for use by GPIO, endstops etc. On Duet 2 WiFi/Ethernet/Maestro they are called "urx0" and "utx0".
The PanelDue port (or IO_0 on Duet 3) can now be configure to operate in raw (non-PanelDue) serial mode using command M575 P1 S2 B### where ### is the required baud rate. In this mode it will default to Marlin-type responses.
There is now a daemon GCode channel, which looks for and executes file sys/daemon.g. This can be used to execute regular tasks. If the end of the file is reached, or the file is not found, it delays for 1 second and starts again.
Experimental support for NeoPixel LED strips has been added for Duet 3. See the M150 X parameter.
Multiple Z probes are supported. M558, G29 and G30 now accept an optional K parameter to specify which Z probe to use. Each Z probe can now have its own deploy and retract files. Z probe number # (where # counts up from zero) looks first for deployprobe#.g and if that is not found it falls back to deployprobe.g. Similarly it uses retractprobe#.g in preference to retractprobe.g. The M401 (deploy probe) and M402 (retract probe) commands now accept an optional P parameter which is the Z probe number to deploy or retract, default 0.
M207 retraction parameters are now settable on a per-tool basis. The P parameter selects which tool to set. M207 with no P parameter applies the parameters provided to all existing tools. Retraction settings in the object model are moved from extruders[].retraction to tools[].retraction.
General purpose inputs may now be configured using M950 J# C"pin-name". These are used by M577 and M581. Their states may be queried in the object model. On Duet 3 they may refer to pins on expansion boards and tool boards as well as pins on the main board.
File runonce.g is now supported. If this file is present at startup, it is run after running config.g and activating the network, and then deleted.
The MakeDirectory and RenameFile local SD card functions now create the full path recursively if necessary
Duet 3: M143 now works for heaters on expansion boards and tool boards
Implemented M952, which is used to set the CAN addresses of tool boards, and exceptionally to alter the CAN bus timing

Changed behaviour (major):

The M581 C parameter (condition) is now replaced by R, in order to allow triggering from a C endstop
Duet 3: firmware updates initiated from SBC now send the same USB and PanelDue messages as other types of firmware update
Tool change files are now run even if the axes have not been homed. If you don't want certain parts to run when axes have not been homed, use conditional GCode in the tool change file.
After a tool change, the user Z coordinate is restored immediately instead of by the end of the next G0 or G1 command.
If a HTTP request is received but insufficient output buffers are available, a HTTP 503 error code is now returned immediately instead of waiting to see if buffers become available and/or discarding response messages. A client receiving a 503 request should call rr_reply to get and flush any pending responses before making any other type of request.
The "laser" field in the rr_status and M408 responses and in state.laserPwm in the object model are now the power that will be used for the next G1, G2 or G3 move instead of the current laser power. This is to allow user interfaces to warn that the laser will turn on as soon as movement starts. New object model field move.current.laserPwm gives the current laser PWM.
A default bed heater is never assigned. In previous 3.01 release candidates, heater 0 was the default bed heater in the Duet 2 WiFi/Ethernet and Maestro builds.
When pausing a job in CNC mode, the spindle speed is now saved in restore point 1
The M308 thermistor H and L parameters on Duet 3 main boards have been re-scaled to match the scaling used on Duet 3 expansion and tool boards.
If the macro stack depth is exceeded, the current macros in the stack are abandoned; and if the macro was called from a GCode print file, that file is abandoned too
Round brackets in GCode lines are no longer treated as enclosing comments if the machine is not in CNC mode
A G4 command will no longer wait for all movement to complete if the input channel executing the G4 has not commanded any motion since it last waited for motion to stop. This is to allow G4 to be used to introduced delays in trigger and daemon GCode files, without causing motion to stop. M400 can still be used to wait for motion to stop.
The I (invert) parameter of M558 has been removed
The parameters to M577 have changed. See https://docs.duet3d.com/User_manual/Reference/Gcodes#m577-wait-until-endstop-is-triggered.
The parameters to M581 have changed. See https://docs.duet3d.com/User_manual/Reference/Gcodes#m581-configure-external-trigger.
The P parameter to M143 now has a different meaning. Also the X (sensor) parameter has been replaced by T. See https://docs.duet3d.com/User_manual/Reference/Gcodes#m143-maximum-heater-temperature. Duet 3: Z probes of types 8 (unfiltered digital) and 9 (BLTouch) connected to expansion boards and tool boards are supported
When tuning a heater using M303 H# the S parameter is now mandatory
The rr_connect message returns additional field "apiLevel":1 if it succeeds. This can be used as an indication that the rr_model command is supported.
In Laser mode, GCode lines with coordinates etc. but no G or M command are now accepted if the most recent command was G0, G1, G2, or G3. This was already the case in CNC mode.
The speed factor (M220) is no longer applied to extruder-only moves or to movement commands in system or user macro files

Changed behaviour (minor):

Previously, if a response for an over-long filename was received by the HTTP server, a "Filename too long" error message was generated and no response to the HTTP command was returned. Now, a 404 response is returned, and a message warning about a possible virus attack is generated unless the filename looks like an OCSP request.
M575 P0 indicates whether the USB interface is in the connected state
M575 P1 says if the aux channel is disabled
M122 Telnet responder line now gives the number of Telnet sessions
[Duet 2] the stepper driver microstep counters are checked and cleared whenever VIN power is applied or reapplied. This is to combat the phantom stepping that sometimes occurs.
HTTP command rr_gcode with no gcode parameter now returns the buffer space, and rr_gcode with an empty gcode parameter no longer adds an empty command to the buffer
[Duet 2]: added I2C transaction count and transactions/minute to M122 diagnostics
Added longest SD card read time (since last M122) to diagnostics
Longest SD card write time in diagnostics now excludes delays inserted by RRF between retries and the CRC calculation time
When in laser mode, at the end of a SD file print the laser power for the next move is set to zero automatically even if the job file didn't request it
The heater fault messages have been improved (thanks gtj0)
Recent versions of S3D changed the print time comment when the print time is at least 1 hour but less than 2 hours. RRF now recognises the new format.
M308 thermistor H and L parameters are now constrained to the range -128 to +127.
M915 now reports the axis or extruder speed that corresponds to the fullsteps/second value of the H parameter
[Duet 2] Increased maximum number of axes on Duet 2 WiFi/Ethernet from 9 to 10
Increased maximum stack/macro file depth from 5 to 7
Duet 3: an emergency stop now tries to stop all CAN-connected expansion boards and tool boards
When a GCode channel locks movement and waits for movement to stop, if there is no movement but moves have been queued, those moves are now executed immediately. Previously there could be a short delay before they were executed.
On Duet 3, increased maximum heaters per tool from 4 to 8, maximum extruders per tool from 6 to 8, maximum bed heaters from 9 to 12, maximum total heaters to 32 and maximum extra heater protection instances to 32

Bug fixes:

[Duet 3]: the default value written to the TMC5160 PWMCONF register did not match the default value for that chip
[Duet 3 with SBC]: Fixed a very small memory leak when DCS sent a height map to RRF
[Duet 3 with SBC]: Fixed loss of output buffers when the USB interface became disconnected and generic messages were generated
[Duet 3 with SBC]: Array parameters in G- and M-commands were not bounds checked
[Duet 3 with SBC]: File-related commands sent from USB ior from a PanelDue connected to the Duet now work (if sending from a PanelDue then it must have firmware 1.24 or later)
Using the M591 (configure height following mode) command caused a firmware crash and reset in some configurations
[Duet 2 and DueX]: depending on the configuration, the response to a M122 command sent from DWC 2.1.5 might be discarded due to insufficient output buffers
[Duet + SBC]: when sending commands from USB or a raw aux port on the Duet and in Marlin response mode, certain commands (e.g. G28, G32) did not return the "ok" response
[Duet + SBC]: pauses commanded by filament monitors sometimes caused a system hang or other undesirable behaviour
Pause and resume sometimes caused a small Z shift if bed compensation was in use and the tool had an X or Y offset
If you used the M581 C parameter and you had a C axis, it would trigger on changes to the state of the C endstop
Disabling a trigger response to an input or endstop using the C-1 parameter didn't work
Duet 3 with SBC: SPI timeout errors were sometimes reported when a command used a CAN address for which no board was present
When the minimum extrusion or retraction temperature was changed using M302, the updated values were not reported in the rr_status and M308 responses (this is long-standing bug)
Non-movement commands that needed to be synchronised to the movement queue were sometimes executed too early
M3 and M5 commands in laser mode were sometimes executed too early, typically by 1 move
Under some conditions a PanelDue or similar client might not fetch all the waiting responses, leading to responses being delayed or lost, or temporarily running out of output buffers
Empty responses to commands were being sent to PanelDue instead of being suppressed
If nested config.g files were used (e.g. because M505 was used to change the system folder) then the effect of M83, G1 Fxxx etc. commands in the nested file were lost
If an extruder-only move specified a feed rate, and the following printing move didn't specify a feed rate because it happened to be the same as the feed rate of the extruder-only move, then the speed factor wouldn't get applied to that move. Likewise if a GCode file used a G1 Fxxx line with no movement in order to dset the feed rate of the following moves, the speed factor would not be applied to those moves.
M409 incorrectly allowed the '.' to be omitted between the closing square bracket of an index and the following field name
On Duet 3 in standalone mode, on the Ethernet interface the limit on the number of MDNS services was set too low, so only the 'echo' service was created
The seconds in the last-modified times of files were reported incorrectly (this was a long-standing bug)
In five-bar SCARA kinematics, the X and Y motors were not treated as continuous rotation axes (thanks bondus)
When M32 was run a second time, the line numbering was not reset
Round-robin scheduling of GCode input sources has been restored so that no channel can monopolise the motion system
On some Duet 3 boards, axes were not flagged as homed when VIN power was lost but 5V power remained
When using the M109 command, the firmware did not prevent you from setting temperatures that exceeded the limit set by M143
The RPM of non-thermostatic fans with tachos wasn't reported continuously
When an under-voltage event occurs, all axes are now flagged as not homed
The maximum step rate possible was reduced in earlier RRF3 releases. Some of that loss has been restored.
When the C (temperature coefficient) parameter was used in the G31 command, if the temperature could not be read from the sensor specified in the H parameter then the error message was not clear; and it didn't allow time for the sensor to become ready in case it had only just been configured.
The M917 command didn't work on Duet 3 and Duet Maestro.
Fixed two instances of possible 1-character buffer overflow in class OutputBuffer
If no heaters were configured, one spurious heater was reported in the status response
[Delta Kinematics]On delta printers, M564 S0 didn't allow movement outside the print radius defined in M665
On Duet 3 with attached SBC, when a job was paused and then cancelled, a spurious move sometimes occurred

RepRapFirmware 3.0

Recommended compatible firmware:

Duet Web Control 2.0.4
DuetWiFiServer 1.23
DuetSoftwareFramework 1.2.2.0
Duet3Firmware_EXP3HC 3.0

Upgrade notes:

If you are upgrading from RepRapFirmware 2.x then you will need to make substantial changes to your config.g file. See https://docs.duet3d.com/en/User_manual/RepRapFirmware/Migration_RRF2_to_RRF3 for details.
Duet Maestro users: the M917 command does not work in this release. If you use M917 in config.g or any other files, we suggest you comment it out all M917 commands until you can upgrade to version 3.01.

The remaining items affect users of RepRapFirmware 3.0 beta (but not RC) versions:

Endstop type S0 (active low switch) is no longer supported in M574 commands. Instead, use type S1 and invert the input by prefixing the pin name with '!'.
If you are using Duet 3 expansion or tool boards, you must upgrade those to 3.0 too
You should also upload the new IAP file for your system. You will need it when upgrading firmware in future. These files are called Duet2CombinedIAP.bin, DuetMaestroIAP.bin, Duet3_SBCiap_MB6HC.bin (for Duet 3 in SBC mode) and Duet3_SDiap.bin (for Duet 3 standalone systems). Leave the old IAP files on your system, they have different names and you will need them again if you downgrade to older firmware.
Duet 3 users: there is no longer a default bed heater. To use Heater 0 as the bed heater, put M140 H0 in config.g (later in config.g than your M950 H0 command).

Known limitations:

Duet 3 users: connector IO_0 of the MB6HC board is currently reserved for PanelDue. We recommend that you do not use it for any other purpose.
Duet 3 users: support for expansion boards has some limitations. See https://docs.duet3d.com/en/User_manual/RepRapFirmware/CAN_limitations for details.
Duet Maestro and Duet 3 users: the M917 command does not work properly and must not be used.

Bug fixes since 3.0RC2:

Fixed issue where a missing start.g could disrupt the G-code flow with an attached SBC
When RRF requested a macro file but had to wait for the SBC to connect, the final code replies to DSF were omitted

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Changelog RRF 3.x

RepRapFirmware 3.5.3

RepRapFirmware 3.5.2

RepRapFirmware 3.5.1 stable (changes since 3.4.6)

RepRapFirmware 3.5.0 stable (changes since 3.4.6)

RepRapFirmware 3.4.7 (in preparation)

RepRapFirmware 3.4.6

RepRapFirmware 3.4.5

RepRapFirmware 3.4.4

RepRapFirmware 3.4.3

RepRapFirmware 3.4.2

RepRapFirmware 3.4.1

RepRapFirmware 3.4.0

RepRapFirmware 3.3

RepRapFirmware 3.2.2

RepRapFirmware 3.2

RepRapFirmware 3.1.1

RepRapFirmware 3.1.0

RepRapFirmware 3.0

Clone this wiki locally