Changelog RRF 3.x

RepRapFirmware 3.4.7 (in preparation)

Upgrade notes: none since 3.4.6

Bug fixes:

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

Internal changes:

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

RepRapFirmware 3.4.6

Upgrade notes:

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

New features since 3.4.5:

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

Bug fixes:

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

RepRapFirmware 3.4.5

Upgrade notes:

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

Bug fixes:

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

RepRapFirmware 3.4.4

Upgrade notes: none since 3.4.1

New features:

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

Bug fixes:

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

RepRapFirmware 3.4.3

Upgrade notes: none since 3.4.1

New features:

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

Bug fixes:

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

RepRapFirmware 3.4.2

Upgrade notes: none since 3.4.1

New features:

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

Internal changes:

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

Bug fixes:

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

RepRapFirmware 3.4.1

Upgrade notes:

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

New features and behaviour changes:

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

Object model changes:

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

Bug fixes:

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

RepRapFirmware 3.4.0

Upgrade notes:

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

New features and changed behaviour:

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

Object model changes:

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

Internal changes:

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

Bug fixes:

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

RepRapFirmware 3.3

Known issues:

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

Upgrade notes:

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

New features:

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

Object model changes:

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

Bug fixes:

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

RepRapFirmware 3.2.2

Upgrade notes: none since 3.2

Bug fixes:

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

RepRapFirmware 3.2

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

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

Known issues:

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

New features:

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

Object model changes:

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

Bug fixes:

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

Other improvements and changes:

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

RepRapFirmware 3.1.1

Recommended compatible firmware:

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

Upgrade notes:

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

New features/changed behaviour:

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

Bug fixes:

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

RepRapFirmware 3.1.0

Recommended compatible firmware:

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

Upgrade notes:

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

Known issues and limitations:

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

New features:

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

Changed behaviour (major):

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

Changed behaviour (minor):

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

Bug fixes:

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

RepRapFirmware 3.0

Recommended compatible firmware:

Duet Web Control 2.0.4
DuetWiFiServer 1.23
DuetSoftwareFramework 1.2.2.0
Duet3Firmware_EXP3HC 3.0

Upgrade notes:

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

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

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

Known limitations:

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

Bug fixes since 3.0RC2:

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Changelog RRF 3.x

RepRapFirmware 3.4.7 (in preparation)

RepRapFirmware 3.4.6

RepRapFirmware 3.4.5

RepRapFirmware 3.4.4

RepRapFirmware 3.4.3

RepRapFirmware 3.4.2

RepRapFirmware 3.4.1

RepRapFirmware 3.4.0

RepRapFirmware 3.3

RepRapFirmware 3.2.2

RepRapFirmware 3.2

RepRapFirmware 3.1.1

RepRapFirmware 3.1.0

RepRapFirmware 3.0

Clone this wiki locally