Changelog RRF 3.x RC

RepRapFirmware 3.5.3-rc.1 (changes since 3.5.2)

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)
[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
[Duet3 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

RepRapFirmware 3.5.2-rc.1 (changes since 3.5.1)

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.
[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.

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.
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 with 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 he 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 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] Fixed stack underflow messages

RepRapFirmware 3.5.0 stable (changes since rc.4)

Bug fixes:

Some expressions that were evaluate correctly in 3.4.x provoked "Expression nesting too deep" errors because of increase stack usage
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

RepRapFirmware 3.5.0-rc.4 (changes since rc.3)

Upgrade notes/breaking changes:

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).

Feature improvements and changed behaviour:

Filament monitor calibration data is reset when a magnetic or laser filament monitor is disabled and then enabled.
M111 B parameter has been added
Maximum stored length of a build object name had been increased from 50 to 100 characters
M308 command now has optional additional U and V parameters to facilitate temperature correction
M950 F command now has optional additional K parameter to set the tacho pulses per revolution
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 M36 returns an error response it now includes the filename concerned in that response
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
When using multiple motion systems, M400 now releases all axes and extruders that are not used by the current tool unless the S1 parameter is used
M950 with E parameter no longer reports frequency if the specified frequency is ignored (i.e. not using DMA)
M591 when used with magnetic filament monitors now reports "firmware version #" instead of "v#"
G17/18/19 no longer wait for motion to stop if the plane being selected is the same as the current one
The Z axis can now be mapped on a per-tool basis (previously only X and Y could be mapped)
[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 - [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
[EXP1HCL] [M23CL] Failed-to-maintain-position warnings did not generate events; they now generate driver-warning events
[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) second input stream to execute commands for the second movement system; otherwise commands for both movement system are executed by the primary file stream.

Object model changes:

Added fields offsetAdj and slopeAdj to sensors.analog[]
Added field tachoPpr to fans[]
Added field boards[].accelerometer.orientation

Bug fixes:

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
[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 TOOL1LC] [Duet 3 TOOL1RR] [Duet 3 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
[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 TOOL1LC] Very short moves could cause extrusion to stop during printing moves although extruder-only movement still worked

RepRapFirmware 3.5.0-rc.3 (changes since rc.2)

Upgrade notes:

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.
[Duet 3 MB6HC] [Duet 3 EXP3HC] [Duet 3 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 2] [Duet Maestro] The number of HTTP responders has been reduced from 4 to 3. This should not matter unless you have HTTP connections to the Duet open on several PCs or in several browser tabs, or you upload files from two or more PCs or browser tabs concurrently.

Reported/suspected issues:

A small number of users have reported unusual noises and/or layer shifts on some prints when input shaping is enabled.
One user has reported a tool board ceasing to extrude correctly part way through a print

Feature improvements and internal changes:

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.
[Duet 2] The amount of free RAM has been increased by about 1.5kbytes
[SZP] [TOOL1RR] Scanning Z probes can now be used as regular Z probes, but note that the trigger height is likely to vary with temperature; so you will need to calibrate and configure temperature compensation.
[Duet 3] In Duet 3 main boards with Ethernet interface, TCP sockets now support backlogs
Upgraded to FreeRTOS 11.0.1. Task wait/notify functions now use indexed notification.

Object model changes:

Added sensors.probes[].measuredHeight which is reported for scanning Z probes only
Added boards[].freeRam
sensors.probes[].scanCoefficients[] values are now reported to 7 decimal places

Bug fixes:

Scanning Z probes sometimes reported many I2C errors and didn't update the sensor reading as often as they should have
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
Under some conditions, when multiple motion systems were used then sync between them could fail
When using multiple motion systems with mesh bed compensation, the motion system that owns the axes that are compensated needs to own the Z axis too
[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 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.

RepRapFirmware 3.5.0-rc.2 (changes since rc.1)

Upgrade notes:

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.
For WiFi-equipped main boards, the recommended WiFi module firmware version is 2.1beta6

New features and behaviour changes:

M593 L parameter has a new meaning, see the Upgrade Notes
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
Improved CAN diagnostics in the M122 report

Object model changes:

Field move.shaping.minAcceleration is replaced by move.shaping.reductionLimit
The following fields are added to sensors.filamentMonitors[] for magnetic and laser filament monitors only: avgPercentage, lastPercentage, maxPercentage, minPercentage, totalExtrusion. They will only be present if the filament monitor is enabled and calibration has completed.
New key 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.

Bug fixes:

Filament monitors connected to main boards used as expansion boards didn't work
Under some conditions a magnetic, laser or pulsed filament monitor would stop comparing measured vs commanded extrusion, as a result no errors were generated when these did not match
The output from M591 when just the D parameter was specified was truncated for some types of filament monitor under some conditions (issue 908)
If a magnetic or laser filament monitor was disabled and re-enabled while a job was executing, on re-enabling the filament monitor it reported a filament error immediately (issue 918 - new bug in 3.5.0-rc.1)
DHT temperature/humidity sensors might sometimes become unresponsive after some time (issue 919). We've made improvements to reduce the occurrence of this, but the underlying issue is that some types of DHT22 or compatible sensors are prone to locking up of they receive unexpected data, for example if the cabling to the sensor picks up noise from an adjacent stepper motor cable.
If the machine position was read from the object model immediately after executing a M400 command then it often reported the position slightly before motion stopped (issue 921)
The file position of an executing job reported in the object model was sometimes incorrect immediately after a macro invoked by the job completed (issue 901)
The file position of an executing job reported in the object model was incorrect when the job was waiting for a response to a M291 dialog (issue 902)
In menu files for a 12864 display it was not possible to include a double-quote character in the command string for an A parameter (issue 909). This made it impossible to use the M98 command in such a parameter because the P argument of the M98 command must now be enclosed in double quotes.
It was not possible to update the bootloader on a TOOL1LC board (issue 903 - new bug in 3.5.0-rc.1)
SD card jobs sometimes didn't quite complete (issue 899)
When the firmware on a CAN-connected expansion board was updated, object model data for other expansion boards was lost. This could result in other boards having incorrect configuration settings if config.g was re-run.
After Emergency Stop was activated, under some conditions some movement would occur after a short pause
Commands M3 and M5 no longer worked properly when the machine was in laser mode
In the object model the type name for a simple switch-type filament monitor had unintentionally be changed from "simple" to "switch". This has been reverted.
[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

RepRapFirmware 3.5.0-rc.1 (changes since 3.5.0-beta.4)

Upgrade notes:

[Duet 2] The standard Duet 2 build no longer supports 5-bar SCARA kinematics. It should still be possible to compile a binary that support this kinematics, but you will have to disable another kinematics (e.g. ordinary SCARA, or linear delta) to free up enough space in flash memory.
M98 now requires the P parameter to be a quoted string. Previously, in standalone mode an unquoted string was permitted.
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}.

New features and behaviour changes:

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.
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.
The limit on block nesting is increased to 65535 (was previously 10)
Main board firmware RAM usage has been reduced by about 1.5kbytes
A simple filament presence detector (i.e. type 1 or 2 in the M591 command) no longer needs to be connected to the same board as the extruder drive
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
The M122 diagnostic report now includes input shaping statistics
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
[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 TOOL1LC] [SAMMYC21] LDC1612-based scanning inductive sensors are supported experimentally (Z probe type 11)
[Duet 3 EXP1HCL] Torque mode is supported experimentally
[Duet 3 EXP1HCL] Version 2.0 prototype boards are supported

Object model changes:

sensors.probes[].diveHeights[] is added, an array of two elements
sensors.probes[].diveHeight is flagged obsolete. It returns the same value as sensors.probes[].diveHeights[0].
For locally configured sensors only, the following fields are added: sensors[].port, sensors[].rRef(for thermistors, PT100 and PT1000 only), { sensors[].r25, sensors.beta, sensors.c } (for thermistors only)
sensors.probes[].scanCoefficients is added, either null or an array of four elements
sensors.analog[].{beta,c,r25,rRef} are added
Field sensors.filamentMonitors[].enableMode is added, with value 0, 1 and 2 to match the S parameter of the most recent M591 command for that extruder
Field sensors.filamentMonitors[].enabled is flagged 'obsolete'
Field 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.

Bug fixes:

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
If G53 was used to specify that tool offsets etc. should be ignored for the rest of the line, and M579 was used to scale the axes, then the tool offset wasn't properly removed
When setting the gateway and/or netmask for an Ethernet interface manually, the gateway and netmask values were swapped
[Duet 3] A spurious "Invalid handle" error was reported when creation of a Z probe on an expansion board failed
[Duet 3 EXP1HCL] PWM brake voltage control didn't work
[Duet 3 TOOL1LC] In some configurations the board would reset with an Out Of Memory error, especially when using the more advanced forms of input shaping
[RPi Pico used as a CAN-connected expansion board] It was not possible to change the CAN address from the default

RepRapFirmware 3.4.6-rc.1 (changes since 3.4.5 stable)

New features:

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
Added support for version 1.01 of MB6XD main board
When the main board executes a stuck-in-spin-loop reset it now saves the relevant stack entries in the software reset data
On processor 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
[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:

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
[Duet 2 WiFi] [Duet 3 Mini WiFi] Before the WiFi module had been enabled, M122 reported random large numbers of WiFi errors
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
Fixed nested lock on endstops when fetching object model, which could cause an unexpected reset if endstops were reconfigured while the object model was being fetched
Increased the amount of the GCode job file that we scan at the start, to allow for larger thumbnail images
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 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.2 stable (changes since 3.4.2RC3+)

New features:

[Duet 3] 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

Bug fixes:

[Duet 3 MB6XD] M915 was not supported so the stall parameters of drivers on CAN-connected expansion boards could not be set
[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

RepRapFirmware 3.4.2RC3+

Internal changes:

Changed linker command lines to work with Eclipse 2022-06
Input conversion functions no longer use 'pow', to save flash space

New features:

[Duet 3 EXP1HCL] When a magnetic encoder is used, M122 reports additional diagnostic information

Bug fixes:

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
[Duet 2] M122 caused a reset in 3.4.2rc2
[Duet 3 MB6XD] M917 was not supported, so the standstill current percentage on expansion board drivers could not be set
[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

RepRapFirmware 3.4.2RC2

New features and other improvements:

Multicast discovery protocol is now supported by the Duet 3 MB6HC and MB6XD. This is an OEM-defined protocol; we recommend that most users use mDNS instead to discover Duets on a network.
Increased the number of decimal places provided for temperature readings in the object model from 1 to 2
Added a workaround to avoid undefined symbols in the link phase when building RRF under Eclipse 2022-06
[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.27beta1.
[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)

Bug fixes since 3.4.2RC1:

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.
[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.

RepRapFirmware 3.4.2RC1

Upgrade notes: none since 3.4.1

New features since 3.4.1:

When configuring a PT100 sensor using M308, the optional R parameter (reference resistor) can now include fractional parts.
[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

Bug fixes since 3.4.1:

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
[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

RepRapFirmware 3.4.1 stable (changes since RC2)

Upgrade notes: none since 3.4.0

Bug fixes:

M581 P parameter did not allow multiple comma-separate values enclosed in { }

RepRapFirmware 3.4.1RC2

Upgrade notes: none since 3.4.0

New features and behaviour changes:

[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 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
Added support for third M950 K parameter to configure idle PWM for spindles

Object model changes: none since 3.4.1RC1

Bug fixes:

[Duet 2 Ethernet] [Duet Maestro] Uploads of large files sometimes failed with CRC errors, especially if a print or simulation was in progress

RepRapFirmware 3.4.1RC1

Upgrade notes: none since 3.4.0

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 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
[EXP1HCL] Duet 3 1HCL v0.3 boards are no longer supported.

Object model changes:

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

Bug fixes:

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 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 stable (changes since RC2)

Upgrade notes:

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.

New features and changed behaviour:

When M575 P1 Bxxxx S4 or S5 is used to ignore incoming commands that do not have a valid CRC, M409 commands are no longer exempted from this requirement.
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 MB6XD] The response to M569 p# where # is a drive designator not includes the actual step timings used as well as the requested step timings
[Duet 3 MB6HC] [Duet 3 MB6XD] Maximum extruders per tool is increased to 10 and maximum heaters per tool to 20

Bug fixes:

The heater feedforward when the print cooling fan speed was changed was incorrect, resulting in the heater temperature rising when the fan speed was changed
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.
[Duet + 12864 display] Value field codes N538 (current move requested speed) and N539 (current move top speed) always printed as zero
[Hangprinter kinematics] When generating a resurrect.g file the M669 command was incomplete
[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.4.0RC2

Upgrade notes: none since 3.4.0RC1

New features and changed behaviour:

M39 now reports the partition size as well as the other SD card data
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.
[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

Object model changes:

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)
[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.

Bug fixes:

If M915 was invoked with parameter R2 or R3 then no action was taken on a driver stall as if R0 had been used (new bug in 3.4.0beta7/3.4.0RC1)
The firmware did not recognise the ending comment for QOI thumbnails produced by recent PrusaSlicer builds. On PanelDue this resulted in the thumbnail having a ragged bottom edge. In DWC this resulted in the thumbnail not being displayed.
The M220 speed factor and M221 extrusion factor were output to only 2 significant digits in the object model, causing PanelDue and DWC to display values above 100% to the nearest 10%
The p, i and d fields of object model field heat.heaters[].model.pid were reported to too few decimal places, which sometimes resulted in them being reported as zero.
The fields of move.compensation.meshDeviation in the object model were not updated when a height map is loaded (old bug)
[Duet + SBC] After a M80 or M81 command was used to configure the power supply control port, the type of variable 'state.deferredPowerDown' returned by RRF in the object model did not match the type expected by DSF. This caused the processing of other members of 'state' to be aborted. In particular this prevented M291 messages being displayed by DWC.
[Duet 3 Mini] If pin io1.out was configured as a servo or PWM pin then only the first PWM or servo value sent to it worked
[Duet 3 with expansion/tool boards] If an axis motor was controlled by an expansion board then if the endstop switch was already triggered when a homing move was commanded, unexpected motion sometimes occurred
[EXP1HCL] In version 1.0, the 12V rail voltage was reported to be about 50% higher than the actual value
[EXP1XD] [EXP1HCL] After a homing move or a probing move involving a motor driven by a EXP1XD or EXP1HCL board, the motor squealed or moved unpredictably

RepRapFirmware 3.4.0RC1

Upgrade notes:

The handling of filament errors have 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 M1 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
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 MB6HC in standalone mode] [Duet 3 Mini Ethernet in standalone mode] 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 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
Increased maximum extruders to 8 on Duet 3 Mini
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
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
M569.2 is now implemented on CAN-connected expansion boards
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 t 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.
[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 these prototype boards has been added
[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).
[EXP1HCL] The EXP1HCL closed loop driver board is now supported

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

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
[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

RepRapFirmware 3.3 post RC3

New features:

Layer numbers are now deduced when printing GCode files generated by SuperSlicer
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)
[Duet + SBC] SBC interface diagnostics have been improved

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
[Duet 2] [Duet Maestro] and [Duet 3 MB6HC] The board would reset if a very long message was sent to a serial port
[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 3 MB6HC] The Aux1 port did not work
[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] Under some situations the Heat task stack overflowed, causing the main board to reset
[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] When a large number of very short movements was commanded by the GCode file being printed, and the movements involved CAN-connected motors, the resulting CAN messages could be delayed. This resulted in print quality issues and a high "max overdue" value reported in the expansion board diagnostics.
[Duet 3 with expansion/tool boards] Spurious CAN transmit timeouts were reported by main boards in the M122 report

RepRapFirmware 3.3RC3

Upgrade notes:

[Duet 3 with expansion/tool boards] The expansion/tool board firmware must be updated too, otherwise you will see "Discarded message" warnings, "oos" errors in the M122 report, and perhaps other warning and error messages

New features:

In the G38.2 command, parameter K can now be used to select the probe number
The tracking and reporting of CAN errors in the M122 reports have been improved

Bug fixes:

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)
M955 was supposed to have an upper frequency limit (Q parameter) of 10000000 but the limit was actually 9999999
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
[Duet + SBC] RRF updated job.lastFileName as soon as the print started. This confused DSF, causing it not to append the simulated time info to the file when a simulation completed. RRF no longer reports job.lastFileName while a print is in progress.
[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 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 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

RepRapFirmware 3.3RC2

Upgrade notes and behaviour changes:

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.
The M593 P parameter is now a string. Valid values in this release are "none" and "daa" or uppercase versions of those.

Feature improvements:

M568 An parameter is supported, allowing the heater temperatures for a tool to be set to the active or standby values (or the heaters turned off) without selecting or deselecting the tool
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

Object model changes:

Restore points now have an additional field 'fanPwm'

Bug fixes:

After using G18/G19 to change the selected plane to XZ or YZ the G2/G3 command K parameter should be recognised
G2/G3 moves were executed in the wrong direction after G18
Removed support for implicit G2/G3 commands because they is not part of the NIST GCode standard
Fixed division by zero under some conditions when using an accelerometer connected to the main board
Limit accelerometer SPI frequencies to 500000 to 10000000 (500kHz to 10MHz)
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
When calling a macro, parameters to the macro could not be expressions that referred to local variables or to parameters that were passed to the calling macro
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

RepRapFirmware 3.3RC1

Upgrade notes: none since 3.3beta3

Known issues:

When G18 or G19 is used to change the selected plane, in subsequent G2/G3 commands RRF continues to look for I and J parameters, instead of looking for (I and K) or (J and K). This will be fixed in the 3.3 stable release.

New features:

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
M955 supports a new optional Q parameter to allow the SPI frequency of the accelerometer to be changed
[Hangprinter Kinematics]Hangprinter kinematics now supports line build-up compensation

Bug fixes:

Thermocouple sensors could not be configured because M308 didn't accept more than 20 characters in the sensor type name
The Move task stack could overflow in some configurations
The Heat task stack could overflow when tuning a heater in some configurations
Babystepping might cause unwanted behaviour due to multiple tasks accessing the movement queue
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
When using two F values in M558 for fast-then-slow probing, if the A parameter was omitted or set to 1, then a G30 probe stopped after the fast probe and failed to set the Z height
When using two F values in M558 for fast-then-slow probing, if the Z axis had not already been homed, then after the fast probe Z would be moved to the original height instead of the dive height before doing the first slow probe
[Hangprinter Kinematics]The Hangprinter kinematics code sometimes attempted to take the square root of a negative number
When using an accelerometer, if data collection failed then the accelerometer data file would sometimes contain old GCode or other data that had been previously written to the SD card and subsequently deleted
[Duet + SBC] The SBC task stack might overflow when a 'set' command was received from the SBC and executed
[Duet + SBC] Parameters were not set up when M98 was executed

Object model changes:

[Hangprinter Kinematics]The object model for Hangprinter kinematics had changed. Fields anchorA, anchorB, anchorC and anchorDz have been replaced by a single 4-element array called anchor.

RepRapFirmware 3.01-RC12

Recommended compatible firmware:

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

Upgrade notes:

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.

Known issues and limitations:

All boards: 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 on 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/changed behaviour:

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".
Added 'move.virtualEPos' and 'boards[0].uniqueId' to object model
M486 without parameters now lists the known objects on the build plate
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.
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.

Bug fixes:

Using the M591 (configure height following mode) command caused a firmware crash and reset in some configurations
When changes were made to the filament monitor configuration, DCS and DWC were not notified that the corresponding object mode subtree had changed
[Duet 2] and [Duet Maestro]: the first time a M575 P1 command was used, the B parameter (baud rate) baud rate in that command was ignored, so the default baud rate of 57600 continued to be used
[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

RepRapFirmware 3.01-RC11

Recommended compatible firmware:

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

Upgrade notes:

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.
Legacy 5-point bed compensation is no longer supported
Duet 3 users: Connector IO_0 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
Duet 2 users: if using a PanelDue with a baud rate other than 57600, see under Known Issues below.

Known issues and limitations:

[Duet 2] and [Duet Maestro] with PanelDue: if you use a PanelDue baud rate other than 57600 then the first M575 command to change the baud rate doesn't work. Workaround: use two identical M575 commands in config.g.
See also known issues and limitations for 3.01-RC9

New features/changed behaviour:

The M581 C parameter (condition) is now replaced by R, in order to allow triggering from a C endstop
[Duet 3] The IO_0 connector is no longer dedicated to PanelDue
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.
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
Skew compensation parameters have been added to the object model, in move.compensation.skew
[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
The "unknown value" message when looking up object model values now includes the name of the unknown value
The object model now reports invisible axes as well as visible ones

Bug fixes:

Pause and resume sometimes caused a small Z shift if bed compensation was in use and the tool had an X or Y offset
When an error message occurred in a GCode meta command, the error message included the command number/letter of the previous normal GCode command, which was confusing
When M584 was used to change the visibility of axes, seqs.move was not updated in the object model
It was not possible to set up a M581 trigger to trigger on both low->high and high->low transitions of an endstop or input pin
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 only: SPI timeout errors were sometimes reported when a command used a CAN address for which no board was present
Duet 3 only: Object model value fans[].actualValue was always reported as zero for fans on expansion and tool boards

RepRapFirmware 3.01-RC10

Recommended compatible firmware:

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

Upgrade notes:

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.

Known issues and limitations: as for 3.01-RC9

New features and changed behaviour:

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.
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.
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
When parsing numbers in conditional GCode expressions, excessive numbers of digits no longer give rise to error messages

Bug fixes:

The minimum extrusion and retraction temperatures in the object model were not reported as zero when cold extrusion was enabled, so the DWC extrude and retract buttons remained greyed-out
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)
When the minimum extrusion or retraction temperature was changed using M302, the appropriate object model sequence number was not upated, so DWC and DSF were not aware of the change
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
Error messages from G1 and G2/G3 commands were lost
Literals in conditional GCode were sometimes printed with too few decimal places
After filament load/unload operations, the filament loaded status was sometimes reported incorrectly to DSF and DWC

RepRapFirmware 3.01-RC9

Recommended compatible firmware:

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

Upgrade notes:

If you were using object model variable 'sensors.inputs' then see the note under "Changed behaviour" below.
See also the notes for 3.01-RC8 if upgrading from an earlier version

Known issues and limitations:

All boards: 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.
All boards: if a print is cancelled automatically because of a serious error, the cancellation message is shown on the DWC console but the original error message reporting the problem is often missing
Duet 3: an endstop switch on 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/changed behaviour:

Object model property 'sensors.inputs' is renamed to 'sensors.gpIn'. The 'configured' field of each array element is gone, instead the whole array element is null if that GPIn port has not been configured. The type of the 'value' field has been changed from Boolean to numeric so that we can return analog values in future firmware versions.
Object model properties 'state.gpOut', 'move.axes[].stepsPerMm', 'move.axes[].microstepping', 'move.extruders[].stepsPerMm' and 'move.extruders[].microstepping' have been added

Bug fixes:

Fan RPM reporting latency was sometimes greater than 1 second which caused the ATE to report errors. It has been reduced back to under 650ms.
The fan blip time was longer than had been configured by a random time up to 500ms
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
[Duet + SBC]: when file-related commands from PanelDue (e.g. M20, M36) were sent to DCS for processing, the JSON response sent to PanelDue was corrupted after the first 256 bytes. This meant that PanelDue was only able to retrieve file and macro lists when there were no more than about 9 files, and that file information displayed by PanelDue was often incomplete

RepRapFirmware 3.01-RC7

Recommended compatible firmware:

DuetWebControl 2.1.2
DuetWiFiServer 1.23
Duet Software Framework version 1.3.2 (for Duet 3/Raspberry Pi users)
Duet 3 expansion board and tool board firmware 3.01-RC7

Upgrade notes:

The tool number (P parameter) in a M563 command must now be in the range 0-49
Duet 3 users with expansion or tool boards must use firmware version 3.01-RC7 on those boards too, otherwise tool/expansion board warnings may be reported as errors, and vice versa. It doesn't matter whether you upgrade the main board firmware before or after the expansion or tool board firmware.
See also the notes for 3.01-RC6 if upgrading from an earlier version

Known issues and limitations:

The response to the M122 P1 command is sent as multiple fragments, so the Duet3D ATE doesn't find the board ID in it. This applies to previous 3.01-RC versions too.
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 on 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
Additional limitations apply to Duet 3 systems with expansion and/or tool boards. See https://docs.duet3d.com/en/User_manual/RepRapFirmware/CAN_limitations.

New features/changed behaviour:

Experimental support for NeoPixel LED strips has been added for Duet 3. See the M150 X parameter.
When running a simulation, object model property job.duration is now the simulated time not the actual time
Added object model property job.lastDuration
Times in the object model related to the current job are now reported as integers instead of floating point values
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.
Added restore points to the object model
Added tools and trackedObjects to the Limits section of the object model
Increased the maximum number of tracked object to 30 on Duet 3

Bug fixes:

The object model sequence numbers were not updated when several object model variables were changed, so DSF and DWC did not know they had changed and did not update their copies of them
M950 J# command with no other parameters reported the incorrect state of the input
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
G30 and G29 commands did not set variable 'result' when some types of error occurred, e.g. when the Z probe was already triggered at the start of the probing move.
In the object model the speed factor and extrusion factors were only reported to one decimal place
Other fixes related to communication with DSF

RepRapFirmware 3.01-RC6

Recommended compatible firmware:

DuetWebControl 2.1.0
DuetWiFiServer 1.23
Duet Software Framework version 1.3.0 (for Duet 3/Raspberry Pi users)
Duet 3 expansion board and tool board firmware 3.01-RC5

Upgrade notes:

[Duet 3 in SBC mode] Users of Duet 3 with attached SBC should upgrade to DSF 1.3.0 at the same time as upgrading to this release
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
Reminders for those upgrading from version 2.x firmware: (1) you cannot upgrade to this release directly from 2.x, you must upgrade to the 3.0 release first; and (2) you will need to make substantial changes to your config.g file.

New features/changed behaviour:

When pausing a job in CNC mode, the spindle speed is now saved in restore point 1
[Duet 3]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.
M308 thermistor H and L parameters are now constrained to the range -128 to +127.

Known issues

On Duet 3 the values of vin, v12 and mcuTemp in the object model always read as zero for expansion and tool boards. You can see the actual values using M122.

Known limitations:

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 on 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
Additional limitations apply to Duet 3 systems with expansion and/or tool boards. See https://docs.duet3d.com/en/User_manual/RepRapFirmware/CAN_limitations.

Bug fixes:

On Duet Maestro, M291 S3 commands initiated from the 12864 display did not work
When printing a file, the first layer time was reported incorrectly, and when the print completed the total print time reported was incorrect

RepRapFirmware 3.01-RC5

Recommended compatible firmware:

DuetWebControl 2.0.7 (or 2.1.0 when available)
DuetWiFiServer 1.23
Duet Software Framework version 1.2.5 (for Duet 3/Raspberry Pi users)
Duet 3 expansion board and tool board firmware 3.01-RC4

Upgrade notes:

Reminders for those upgrading from version 2.x firmware: (1) you cannot upgrade to this release directly from 2.x, you must upgrade to the 3.0 release first; and (2) you will need to make substantial changes to your config.g file.

New features/changed behaviour:

G29 and G30 now accept an optional K parameter to specify which Z probe to use
[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.
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 has an extra 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.

Known issues

On Duet Maestro, M291 S3 commands initiated from the 12864 display do not work
When a print completes, the total print time reported in the completion message is incorrect
On Duet 3 the values of vin, v12 and mcuTemp in the object model always read as zero for expansion and tool boards. You can see the actual values using M122.

Known limitations:

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 may only be of type 8 or 9.
Duet 3: an endstop switch on 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
Additional limitations apply to Duet 3 systems with expansion and/or tool boards. See https://docs.duet3d.com/en/User_manual/RepRapFirmware/CAN_limitations.

Bug fixes:

On the Duet Maestro 12864 display the speed factor and extrusion factor items were not converted to and from percentages
Inverting the sense of input pins in analog mode (e.g. for a type 1 Z probe) didn't work

RepRapFirmware 3.01-RC4

Recommended compatible firmware:

DuetWebControl 2.1.0 when available, 2.0.7 until then
DuetWiFiServer 1.23
Duet Software Framework version 1.2.5 (for Duet 3/Raspberry Pi users)
Duet 3 expansion board and tool board firmware 3.01-RC4

Upgrade notes:

M207 (set firmware retraction parameters) without the new P parameter is applied to all existing tools but not to any tools created after the M207 command. Therefore, make sure that your M207 command is later in config.g than all your M563 tool creation commands.
Previously, a M563 command with no P parameter could be used to add a constant (specified in the S parameter) to all tool numbers in GCode commands. This is no longer supported. It was only needed when using very old versions of RRF with old versions of slic3r.
If you have a Z probe that needs to be deployed/retracted, please test that deployment and retraction are working before relying on the Z probe. This is especially important if you are using Duet 3 with attached SBC.

Known issues

On the Duet Maestro 12864 display, speed factor and extrusion factor display and control doesn't work correctly
You can only have one Z probe of type 1, 2 or 5 and if using Duet 3 it must be attached to the main board. You can have multiple Z probes of types 8 and 9 including probes attached to Duet 3 expansion and tool boards.
The G29 and G30 commands only allow the use of Z probe 0
Duet 3: an endstop switch on 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: the values of vin, v12 and mcuTemp in the object model always read as zero for expansion and tool boards. You can see the actual values using M122.
Additional limitations apply to Duet 3 systems with expansion and/or tool boards. See https://docs.duet3d.com/en/User_manual/RepRapFirmware/CAN_limitations.

New features/changed behaviour:

Parameters in commands received from the SBC attached to a Duet 3 may now be expressions, except in parameters that take a colon-separated list of values. Meta commands ('if', 'while' etc.) are still not supported when using an attached SBC.
Round brackets in GCode lines are no longer treated as enclosing comments if the machine is not in CNC mode
Added functions radians(arg) and degrees(arg) which convert the argument from degrees to radians, and from radians to degrees
M915 now reports the axis or extruder speed that corresponds to the fullsteps/second value of the H parameter
Added many more object model properties, including inputs[] describing the state of each GPin, volumes[] describing the attached SD cards, and seqs{} to help DSF and UIs know which non-live object model properties have changed
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.
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 mor retract, default 0.
The daemon GCode task is now enabled even on Duet 3 with attached SBC
The status no longer shows as Busy when the daemon macro file is running, if no other macro is running or movement in progress
Increased maximum number of axes on Duet 2 WiFi/Ethernet from 9 to 10

Bug fixes:

If an array of items in the object model (e.g. heaters, sensors) included null entries because of gaps in the item numbers created, and an object model expression referred to a prioerty of such as null element, the firmware crashed
If a while-loop was not followed by at least one GCode command or meta command outside the loop before the end of the file, the loop was never executed more than once
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
On Duet WiFi, the HTTP rr_model call sometimes caused a reset due to stack overflow
When running true bed levelling or auto calibration, if all probe points had zero height error then the initial deviation could be reported as 'nan'
After triggering for the first time, the status of a Z probe on a tool or expansion board that was not a BLTouch was not subsequently updated, so the state remained as triggered, which prevented further probing

RepRapFirmware 3.01-RC3

Recommended compatible firmware:

DuetWebControl 2.0.7
DuetWiFiServer 1.23
Duet Software Framework 1.2.4.0 (for Duet 3/Raspberry Pi users)
Duet 3 expansion board and tool board firmware 3.01-RC3

Upgrade notes:

If you use a Duet 3 with expansion/tool boards, you must use firmware 3.01-RC3 on those boards. Otherwise remote endstops and GP input pins will no longer work.
See the upgrade notes for 3.01-RC2 if you are upgrading from a version earlier than that

New features/changed behaviour

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. This feature is not yet available on Duet 3 with attached SBC.
Increased maximum stack/macro file depth from 5 to 7
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
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 deamon GCode files, without causing motion to stop. M400 can still be used to wait for motion to stop.
Filament monitor types types 4 (rotating magnet + filament presence switch) and 6 (laser + filament presence switch) now provoide object model property 'filamentPresent'. Types 1 and 2 already did.
Added object model properties 'extruders[].filament' and 'tools[].filament'
Added support for file runonce.g. If this file is present at startup, it is run after running config.g and activating the network, and then deleted.
On Duet 3, an emergency stop now tries to stop all CAN-connected expansion boards and tool boards
On Duet 3, Z probes of types 8 (unfiltered digital) and 9 (BLTouch) connected to expansion boards and tool boards are supported. Other types of Z probe are supported only when they are connected to the main board.
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.

Bug fixes:

When homing switches were already triggered at the start of a homing move, sometimes the move queue got stuck, requiring a reboot
If G10 was used to set the standby temperature of a heater for some tool, and the same heater was an active heater for the current tool, the target temperature would incorrectly be set to the standby value (this was a new bug in 3.01-RC2)
External SD cards didn't work on Duet Maestro
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
Object model variable fans[].actualValue was incorrectly reported to 1 decimal place instead of 2

Other:

In the Duet 3 build, upgraded Lwip (the TCP/IP network stack) from version 2.0.3 to 2.1.2
Integrated PRs from ajquick (for building nonstandard Duet 2 configuration without smart driver support) and wilriker (simplification of fan configuration code)

RepRapFirmware 3.01-RC2

Recommended compatible firmware:

DuetWebControl 2.0.7
DuetWiFiServer 1.23
Duet Software Framework 1.2.4.0 (for Duet 3/Raspberry Pi users)
Duet 3 expansion board and tool board firmware 3.01-RC2

Upgrade notes:

If you use M577 or M581 commands, you will need to change them.
If you use M143 commands with P or X parameters, you will need to change them
If you use M558 commands with the I parameter, you will need to change them

Changed behaviour:

The I (invert) parameter of M558 has been removed. If you were using I1 then you will need to invert the pin name instead.
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.
On Duet 3, M143 now works for heaters on expansion boards and tool boards provided that they are running version 3.01-RC2 of their own firmware
When tuning a heater using M303 H# the S parameter is now mandatory
The speed factor (M220) is no longer applied to extruder-only moves or to movement commands in system or user macro files

New features:

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.
Object model key heat.sensors has been moved to sensors.analog
Object model key sensors.inputs has been added. This lists the input states of the configured general purpose inputs.
Object model key state.previousTool is added. It is the tool number that was active at the start of the last T command that caused a tool change (or implied T command caused by executing M109), or -1 if no tool was active at that time.
Object model key limits has been added. This gives the maximum number of heaters, fans etc. that the firmware supports. It has the verbose flag set, so it is normally hidden. Send M409 k"limits" f"v" to see all the limits.
Object model key network.name has been added. It returns the machine name set by M550.
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.

Bug fixes:

Round-robin scheduling of GCode input sources has been restored so that no channel can monpolise 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

RepRapFirmware 3.01-RC1

Recommended compatible firmware:

DuetWebControl 2.07
DuetWiFiServer 1.23
Duet Software Framework 1.2.4.0 (for Duet 3/Raspberry Pi users)

Upgrade notes:

Object model variables move.initialDeviation and move.calibrationDeviation are renamed to move.calibration.initial and move.calibration.final. If you use these variables in bed.g or in other macro files then you will need to update those files.

New features:

Implemented M952, which is used to set the CAN addresses of tool boards, and exceptionally to alter the CAN bus timing
Added expansion boards and filament monitors to the object model
Added move.calibration to the object model and added numFactors as a property of it
Added move.axes[].babystepping to object model
On Duet 3, increased maximum heaters per tool from 4 to 8, maximum extruders per tool from 6 to 8, maxumum bed heaters from 9 to 12, maximum total heaters to 32 and maximum extra heater protection instances to 32
In conditional GCode, literal 'null' is now provided. Object-valued OM elements can be compared for equality/inequality with null.

Bug fixes:

The M587 command didn't set up the access point password correctly, resulting in "Wrong password" reports when trying to connect to the access point
if..elif GCode meta commands with multiple elif parts sometimes gave rise to error messages "'elif' did not follow 'if'"
When G32 true bed levelling failed (for example, because the correction required exceeded the limit), the initial and final deviation were left unchanged. Now thay are both set to the initial deviation measured by probing.
If the M581 command was used with a T parameter but no P parameter, it reported "missing T parameter".
The machine coordinates returned to DWC and in the object model were not updated
The 'abort' command stopped printing but didn't reset the state to Idle
The 'continue' command was not recognised

RepRapFirmware 3.0RC2

Recommended compatible firmware:

Duet Web Control 2.0.4
DuetWiFiServer 1.23
DuetSoftwareFramework 1.2.1.0
Duet3Firmware_EXP3HC 3.0RC2
Duet3Firmware_Tool1LC 3.0RC2

Known issues:

As for RRF 3.0RC1

Upgrade notes:

As for RRF 3.0RC1

Feature changes:

Increased maximum number of triggers on Duet 3 from 16 to 32
Increased maximum number of heaters on Duet 3 to 16
Increased maximum number of extra heater protections on Duet 3 to 16
Increased maximum number of fans on Duet 3 to 16

Bug fixes:

Fix for M584 sent via SPI to Duet 3 when the first parameter is an array
Fix for analog Z probing when Z probe reports "near" from the start of the move
Fix for M25 while tool changing is is progress
Fix for unexpected diagonal moves during tool changes
Use of M950 to configure heater numbers greater than 5 on expansion boards caused sensors to disappear
The response to M308 with just a S parameter didn't include the sensor name or last reading if the sensor was connected to a Duet 3 expansion board
The G31 response now displays trigger height to 3 decimal places instead of 2
When printing from file on a Duet 3 with attached Raspberry Pi, under some conditions an attempt to retrieve the file position caused RRF to crash

RepRapFirmware 3.0RC1

Recommended compatible firmware:

Duet Web Control 2.0.4
DuetWiFiServer 1.23
DuetSoftwareFramework 1.2
Duet3Firmware_EXP3HC 3.0RC1
Duet3Firmware_Tool1LC 3.0RC1

Known issues:

An endstop switch connected to a Duet 3 main board may only be used to home an axis if at least one motor controlling that axis is driven by the main board
Various Duet 3 expansion board features are not fully implemented. See the RRF3 Limitations document on the wiki.
After installing new expansion or tool board firmware or resetting an expansion or tool board, you must reset the main board or at least run config.g using M98. Otherwise the expansion/tool board configuration will not match the settings expected by the main board.

Upgrade notes:

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.0RC1 too
Duet 3+SBC users must use DSF 1.1.0.5 or a compatible later version with this version of RRF
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+SBC) and Duet3_SDiap.bin (for Duet 3 standalone systems). You can leave the old IAP files on your system, they have different names and you will need them if you downgrade to earlier 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).

Feature changes since beta 12:

Duet 3 only: Switch-type endstops connected to expansion boards are supported
Current position is no longer shown for pulse-type filament monitors, because it was meaningless and nearly always zero
Calibration data for pulse-type filament monitors is no longer displayed by M122 (same as for laser and magnetic filament monitors). Use M591 to report the calibration data.
Max bed heaters increased to 9 on Duet 3, 2 on Duet Maestro (still 4 on Duet 2 WiFi/Ethernet)
Max chamber heaters increased to 4 on Duet 3 and on Duet 2 WiFi/Ethernet
CRC calculation has been speeded up, which improves the speed of file uploads in standalone mode when CRC checking is enabled in DWC
G1 H1 E moves (stopping on motor stall) are now implemented
rr_config and M408 S5 responses now include field "sysdir" which is the system files folder set using M505
M950 P, M950 S, M42 and M280 are implemented on expansion boards
B parameter added to M408 to query expansion boards (for expansion board ATE)
M122 P parameter is passed to the expansion board if the B parameter is present and selects an expansion board (for ATE)

Bug fixes:

Duet 3 only: Files uploaded in standalone modes were frequently corruption during uploading, resulting in CRC mismatches reported
If a print that was sliced using absolute extrusion mode was resurrected, unwanted extrusion occurred just before the print was resumed
Bed compensation did not take account of the XY offset of the printing nozzle from the head reference point
When using SCARA kinematics the calculation of the minimum achievable radius was incorrect. Depending on the B parameter of the M667 command, this could result in spurious "Intermediate position unreachable" errors, or non-extruding G1 moves being turned into G0 moves.
A badly-formed GCode file that returned the layer height or object height as nan or inf caused DWC to disconnect because of a JSON parse failure
M579 scale factors were not applied correctly to G2 and G3 arc moves
M119 crashed if an axis had no endstop
Filament handling didn't work on Duet 3+SBC
If a homing move involved only motors connected to Duet 3 expansion boards and the corresponding endstop was already triggered, the homing move started anyway and didn't stop
Stall detect homing works properly
If an attempt to create a switch-type endstop using M574 failed because the specified pin wasn't available, this resulted in a partically-configured switch endstop

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Changelog RRF 3.x RC

RepRapFirmware 3.5.3-rc.1 (changes since 3.5.2)

RepRapFirmware 3.5.2-rc.1 (changes since 3.5.1)

RepRapFirmware 3.5.0 stable (changes since rc.4)

RepRapFirmware 3.5.0-rc.4 (changes since rc.3)

RepRapFirmware 3.5.0-rc.3 (changes since rc.2)

RepRapFirmware 3.5.0-rc.2 (changes since rc.1)

RepRapFirmware 3.5.0-rc.1 (changes since 3.5.0-beta.4)

RepRapFirmware 3.4.6-rc.1 (changes since 3.4.5 stable)

RepRapFirmware 3.4.2 stable (changes since 3.4.2RC3+)

RepRapFirmware 3.4.2RC3+

RepRapFirmware 3.4.2RC2

RepRapFirmware 3.4.2RC1

RepRapFirmware 3.4.1 stable (changes since RC2)

RepRapFirmware 3.4.1RC2

RepRapFirmware 3.4.1RC1

RepRapFirmware 3.4.0 stable (changes since RC2)

RepRapFirmware 3.4.0RC2

RepRapFirmware 3.4.0RC1

RepRapFirmware 3.3 post RC3

RepRapFirmware 3.3RC3

RepRapFirmware 3.3RC2

RepRapFirmware 3.3RC1

RepRapFirmware 3.01-RC12

RepRapFirmware 3.01-RC11

RepRapFirmware 3.01-RC10

RepRapFirmware 3.01-RC9

RepRapFirmware 3.01-RC7

RepRapFirmware 3.01-RC6

RepRapFirmware 3.01-RC5

RepRapFirmware 3.01-RC4

RepRapFirmware 3.01-RC3

RepRapFirmware 3.01-RC2

RepRapFirmware 3.01-RC1

RepRapFirmware 3.0RC2

RepRapFirmware 3.0RC1

Clone this wiki locally