Changelog RRF 3.x Beta

RepRapFirmware 3.6.0-beta.1

Upgrade notes for users coming from 3.5.2:

• [Duet Maestro] is no longer supported because the MCU on that board does not have floating point hardware.
• The RAM usage of this release is higher than 3.5.2 especially when the more advanced forms of input shaping are used. If the system runs out of RAM during a print it will reset and a subsequent M122 report will show that the cause was an OutOfMemory error. This is most likely to be an issue in Duet 2 and in Duet 3 Mini Ethernet standalone configurations having many tools or many global variables.
• If certain movement error conditions are detected, the machine will halt and a diagnostic message will be generated. This is to reduce the possibility of damage to the machine due to e.g. movement out of limits, or attempted movement too fast for the mechanics to execute. Please report any such messages. You will need to restart the Duet to enable motion again and you will lose the print.
• Delta kinematics now uses segmentation. The default segmentation parameters (max 100 segments/second, minimum segment length 0.2mm) should be suitable for most delta printers.
• When input shaping is used, pressure advance may need to be reduced compared to 3.5.2

Limitations and known issues:

• If the main board introduces hiccups then the expansion board(s) will not be aware of this; so if the main board introduces more than a few hiccups then the expansion board motion will get ahead of it. You can see the cumulative hiccup time in the main board M122 report. Values below 0.1ms are unlikely to cause noticeable problems.

New features since 3.5.2:

• Input shaping is now applied to all moves including very short ones, without reducing sprint speed
• M115 is now executed when a file is being simulated instead of being ignored
• M300 now accepts a C parameter to allow any PWM-capable port to be used for the buzzer
• [Duet 3] M260.1 and M261.1 commands for Modbus RTU register read/write are supported (but the V parameter of M261.1 is not yet supported)

Bug fixes (bugs in 3.6.0-alpha.2):

• The positions of extruders driven by CAN-connected tool/expansion boards were not updated n the object model
• The positions of axes driven by CAN-connected expansion boards were not updated smoothly in the object model. Typically the reported position jumped to the position at the end of the current move segment too early.
• When a directly-connected filament monitor was used a spurious filament error was raised when starting a print after completing the previous print

Bug fixes (bugs also in 3.5.2):

• In SBC mode, when a numeric parameter was expected but a string parameter was provided, the value defaulted to 0 instead of an error being raised (issue 1022, fix not tested yet)
• On main boards that support motor brake PWM (e.g. 6HC, 6XD) using M17 to disable the motor didn't re-engage the brake (issue 1023,)
• A main board used as an expansion board didn't use the idle current percentage commanded by the main board (issue 1019, fix not tested yet)
• It was not possible to use the same name for both a variable and a macro parameter (issue 1003)
• In some contexts, using the # operator to take the length of an array within an array didn't work and the inner array was returned (issue 1020)
• If the # operator was used to take the length of an array within an array in an unevaluated context (e.g. in a ternary operator) a spurious parsing error could be raised (issue 1021)
• [Duet 3 MB6HC] [Duet 3 MB6XD] An attempt to send a MQTT message resulted in a crash if the WILL message had not been set

RepRapFirmware 3.6.0-alpha.2

Upgrade notes for users coming from 3.5.2:

• Only main board firmware is provided. CAN-connected expansion boards running firmware 3.5.2 will interoperate with this release with the limitations listed below. Duet Web Control 3.5.2 will work with this release but it will warn you of incompatible software versions. WiFi firmware 2.1.0 is compatible with this release.
• [Duet Maestro] is no longer supported because the MCU on that board does not have floating point hardware.
• The RAM usage of this release is higher than 3.5.2 especially when the more advanced forms of input shaping are used. If the system runs out of RAM during a print it will reset and a subsequent M122 report will show that the cause was an OutOfMemory error. This is most likely to be an issue in Duet 2 and in Duet 3 Mini Ethernet standalone configurations having many tools or many global variables.
• If certain movement error conditions are detected, the machine will halt and a diagnostic message will be generated. This is to reduce the possibility of damage to the machine due to e.g. movement out of limits, or attempted movement too fast for the mechanics to execute. Please report any such messages. You will need to restart the Duet to enable motion again and you will lose the print.
• Delta kinematics now uses segmentation. The default segmentation parameters (max 100 segments/second, minimum segment length 0.2mm) should be suitable for most delta printers.

Limitations:

• Input shaping will not be applied to any motion controlled by expansion boards; therefore the motors controlling X and Y must be driven by the main board.
• If the main board introduces hiccups then the expansion board(s) will not be aware of this; so if the main board introduces more than a few hiccups then the expansion board motion will get ahead of it. You can see the cumulative hiccup time in the main board M122 report. Values below 0.1ms are unlikely to cause noticeable problems.
• Watch out for very small layer shifts, which may occur due to floating point rounding error. We have not seen these in our test prints, however they may be noticeable in some prints.

New features and behaviour changes since alpha.1:

• Move segments now use less RAM, making it less likely that the machine will run out of RAM
• When a step error occurs the step error type is reported even if debugging has not been enabled
• M300 now accepts a C parameter to allow any PWM-capable port to be used for the buzzer
• [Duet 3 Mini] The M122 report has been shortened a little by removing information that is no longer useful
• [Duet 3 Mini] Increased available RAM especially when in WiFi and SBC modes
• [Duet 3 MB6HC] [Duet 3 MB6XD] Increased available RAM by about 16kb

Bug fixes (bugs introduced in 3.6.0-alpha.1):

• Filament monitors connected to the main board didn't function (this was a documented limitation of 3.6.0-alpha.1)
• At least one cause of step error halts has been fixed
• After calibrating a delta printer the Z=0 position was incorrect until the machine was homed again
• Simulating a file didn't work
• If an axis used multiple motors each with its own endstop, after homing it the motor(s) that stopped early remained disabled

Bug fixes (bugs also in 3.5.2):

• In SBC mode, when a numeric parameter was expected but a string parameter was provided, the value defaulted to 0 instead of an error being raised (issue 1022, fix not tested yet)
• On main boards that support motor brake PWM (e.g. 6HC, 6XD) using M17 to disable the motor didn't re-engage the brake (issue 1023,)
• A main board used as an expansion board didn't use the idle current percentage commanded by the main board (issue 1019, fix not tested yet)

RepRapFirmware 3.6.0-alpha.1

Upgrade notes:

• This firmware is experimental, for testing the new input shaping algorithm only.
• Only main board firmware is provided. CAN-connected expansion boards running firmware 3.5.2 will interoperate with this release with the limitations listed below. Duet Web Control 3.5.2 will work with this release but it will warn you of incompatible software versions. WiFi firmware 2.1.0 is compatible with this release.
• Duet Maestro is no longer supported. The MCU on that board does not have floating point hardware.
• The RAM usage of this release is higher than 3.5.2 especially when the more advanced forms of input shaping are used. If the system runs out of RAM during a print it will reset and a subsequent M122 report will show that the cause was an OutOfMemory error. This is likely to be a particular problem in Duet 2 standalone configurations. It may also be an issue on Duet 3 Mini especially in configurations that use segmented kinematics.
• If certain movement error conditions are detected, the machine will halt and a diagnostic message will be generated. This is to reduce the possibility of damage to the machine due to e.g. movement out of limits, or attempted movement too fast for the mechanics to execute. Please report any such messages. You will need to restart the Duet to enable motion again.
• Debug output may be sent to the USB port under some conditions. If the USB port is connected to a PC but the PC is not running terminal emulation software to receive the output, this may result in a "Stuck in spin loop" or "Heat task stuck" reset.
• Delta kinematics now uses segmentation. The default segmentation parameters (max 100 segments/second, minimum segment length 0.2mm) should be suitable for most delta printers.

Limitations (to be resolved in future releases):

• Input shaping will not be applied to any motion controlled by expansion boards; therefore the motors controlling X and Y must be driven by the main board.
• If the main board introduces hiccups then the expansion board(s) will not be aware of this; so if the main board introduces more than a few hiccups then the expansion board motion will get ahead of it. You can see the cumulative hiccup time in the main board M122 report. Values below 0.1ms are unlikely to cause noticeable problems.
• Filament monitors connected to the main board will not work. You will need to disable any such filament monitors to avoid getting spurious filament errors.
• Delta printers: it has been observed that after homing and running auto calibration (G32) once the Z=0 position is slightly incorrect. Homing and running G32 again before printing appears to resolve the issue.
• Watch out for very small layer shifts, which may occur due to floating point rounding error. We have not seen these in our test prints, however they may be noticeable in some prints.

New features and behaviour changes:

• The input shaping algorithm has been changed. The new algorithm is similar to the one used by Klipper firmware. Compared to the algorithm used in RRF 3.5.x it has the advantage that it can be (and is) applied to any type of move, including short segmented moves. The disadvantage that it introduces artefacts at direction changes (a process which the Klipper documentation optimistically calls "smoothing").
• When configuring custom input shaping using M593 the meaning of the H and T parameters is changed. See this documentation.
• The M593 L parameter no longer serves any purpose so it is ignored.
• In the M122 report the driver status report is now in the Move section instead of the Platform section
• In the object model the machine position of axes controlled by CAN-connected drivers is now updated about every 100ms instead of only at the end of each move (issue 922)

Bug fixes since 3.5.2: none.

RepRapFirmware 3.5.0-beta.4

Upgrade notes:

• LED strips must now be created using M950 with E parameter. M150 commands can specify the strip number using the new E parameter. M150 X and Q parameters are no longer supported.
• M116 without parameters only waits for slow heaters (beds, chambers) and for the selected tool heaters of the current tool (if any) assigned to the current motion system. In previous versions, M116 waited for all heaters to reach their target temperatures
• [Duet 2] Hangprinter kinematics are no longer supported in the standard build of Duet2CombinedFirmware because of lack of flash memory space

New features and behaviour changes:

• M116/M190/M191 are now handled by all file readers
• Up to 5 LED strips can now be configured on most main boards (see Upgrade Notes)
• Expansion boards and main boards used as expansion boards can support LED strips
• Expression parser now supports ceil(x) function
• pow(x, x) now returns an integer if a is an integer, b is a non-negative integer and the result fits in an integer
• The timeout before resetting the processor if the heater control task fails to run has been reduced from 20 to 4 seconds
• HTTP session keys are now supported in standalone mode to support multiple sessions from a single IP address. See the amended rr_connect docs for further information
• Reinstated implicit repetition of a previous G2/G3 command in CNC and laser mode when the line doesn't start with G, M or T and the first letter is instead an axis name
• Driver stall events on main boards are no longer disabled when not printing from SD card
• The minimum arc segment length has been reduced from 0.1mm to 0.02mm
• Fans can now be un-configured by using M950 F# C"nil" where # is the fan number
• WiFi-enabled boards now support some WPA2-Enterprise experimentally. Duet 2 and Duet 3 Mini boards support modes EAP_PEAP_MSCHAPV2 and EAP_TTLS_MSCHAPV2. Duet 3 MB6HC with the optional WiFi module supports those modes and also EAP_TLS. DuetWiFiServer 2.1beta4 must be installed on the WiFi module to enable this support.
• [Duet 2] Pins "connlcd.5", "connlcd.6", "connlcd.7", and "connlcd.8", "connlcd.9" and "connlcd.10" are now available for GPIO if no display is connected to connlcd and they are not being used to support additional stepper drivers
• [Duet 3] When a CAN-connected expansion board has registered its presence with the main board, if the main board stops receiving status messages from the expansion board then an event of type expansion-timeout is raised; or if the expansion board sends a new announce message (indicating that it has reset) an event of type expansion-reconnect is raised.
• [Duet 3] Expansion and tool boards can now generate debug output, which is relayed to the DWC console
• [Duet 3] Increased maximum number of general purpose outputs from 32 to 64
• [Duet 3] Increased maximum number of general purpose inputs from 32 to 56
• [Duet 3] Increased maximum number of fans from 20 to 32
• [Duet 3 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] [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
• [Duet Maestro] Neopixel LED strips are now supported in principle, however this has not been tested. Note, most Neopixel strips require a 5V control signal, whereas the Maestro only provides 3.3V.
• [EXP1HCL] [M23CL] Changes to the closed loop algorithm reduce motor noise in closed loop mode
• [EXP1HCL] [M23CL] Added acceleration feedforward term to closed loop PID parameters and M569.1
• [EXP1HCL] [M23CL] Added an experimental Assisted Open Loop mode

Object model changes:

• The following fields have been removed (they have been flagged 'obsolete' since version 3.3):
  • sensors[].probes[].speed (use sensors[].probes[].speeds[1] instead)
  • sensors[].probes[].temperatureCoefficient (use sensors[].probes[].temperatureCoefficients[0] instead)
  • move.compensation.probeGrid.{axis0, axis1, xMin, yMin, xMax, yMax, xSpacing, ySpacing} (use axes[], mins[], maxs[], spacings[] instead)
• Added limits.portsPerHeater
• Added limits.ledStrips
• Added sensors[].probes[].{calibA, calibB, isCalibrated} for scanning Z probes only
• Added heat.heaters[].monitors[].sensor
• Added ledStrips[] and seqs.ledStrips
• Removed boards[0].directDisplay.{pulsesPerClick, spiFreq, typeName}
• Added boards[0].directDisplay.encoder with field pulsesPerClick
• Added boards[0].directDisplay.screen with fields {contrast, controller, height, spiFreq, width}. For ST7267 displays there are additional fields {resistorRatio, colourBits}.
• Added network.interfaces[].ssid which is the name of the access point that the wifi module is connected to. Only present when the interface is a WiFi interface and it is connected.
• Field network.interfaces[].mac is no longer populated if the interface is a WiFi interface and it is disabled. In previous firmware versions, incorrect data was returned when the WiFi module had not been enabled.
• Fields boards[0].directDisplay.{pulsesPerClick, spiFreq, typeName} are removed. They are replaced by boards[0].directDisplay.encoder.pulsesPerClick and boards[0].directDisplay.screen.{colourBits, controller, height, spiFreq, width}.
• Added network.interfaces[].ssid when the interface is WiFi

Bug fixes:

• If a print was paused when the speed factor was not 100% then when the print was resumed, the speed factor was applied again until a G0/1/2/3 command with F parameter was executed
• Extruders sometimes extruded when they should retract and vice versa (new bug in 3.5.0-beta.3)
• Some prints exhibited sections of missing extrusion, especially when the extruder was driven from a tool board (new bug in 3.5.0-beta.3)
• DHT sensor support didn't work
• G2/G3 moves for which the complete circle would infringe and keepout zone sometimes caused an assertion failure leading to a reset
• "echo tools" return an incorrect string
• M669 behaved unexpectedly when more matrix columns than configured axes were supplied
• Using N{expression} in a 12864 display menu file didn't work
• Error handling for array indices in set command was missing in SBC mode leading to potential unexpected resets
• It was not possible to use extruder stall detection for filament loading
• [Duet 3 6HC] [Duet 3 Mini] MDNS name lookup didn't work from some Mac and Linux PCs
• [Duet 3 MB6HC] When the optional WiFi module was installed, command M552 I1 S1 in config.g often failed to enable it, even though it worked when sent manually
• [EXP1XD] [EXP1HCL] [EXP3HC] TOOL1LC] [M23CL] The number of out-of-sequence motion commands received was reported incorrectly by M122 (new bug in 3.5.0-beta.3)
• [Duet 3 MB6HC] [Duet 3 MB6XD] [Duet 3 Mini Ethernet] Fixed mDNS support
• [Duet 3 MB6HC] [Duet 3 MB6XD] [Duet 2] [Duet Maestro] On the PWM peripheral, PWM frequencies down to 1Hz are supported again

RepRapFirmware 3.5.0-beta.3

Breaking changes since 3.5beta2:

• Object model field move.workspaceNumber has been removed (this field has been flagged obsolete since RRF 3.3)
• Expansion board firmware must also be updated to 3.5.0beta3 otherwise motors connected to expansion boards will not work
• If you are running version 2.x WiFi module firmware then you must update it to version 2.1beta4

New features and behaviour changes:

• M3 M4 and M5 commands are now supported in FDM mode (previously they were supported in CNC mode and M3 was supported in laser mode)
• M122 now includes the connected channel number in the WiFi section when running version 2.x WiFi firmware
• M472 (delete file or folder, optionally recursively) has been added
• M558 supports new Z probe type 11 (scanning analog probe), however implementation is incomplete and dummy data is recorded
• M574 with no parameters no longer waits for movement to stop before reporting on the endstops
• M587.2 report now includes the channel number and MAC address of each access point found
• M587.2 report in JSON format: the rssi value is now reported as an integer instead of a string
• M599 with any axis parameters now removes all unmentioned axes from the keepout zone definition
• Input shaping is now supported on axes driven by CAN-connected expansion boards
• When input shaping is used, extruder motion is now synchronised to the shaped axis motion
• HTTP API call rr_delete now takes an optional "recursive=yes" parameter
• The FTP server now supports the optional directory parameter in the LIST command
• When an unexpected software reset occurs the floating point registers are now omitted from the stack trace, which makes it more useful
• When a "stuck in spin loop" or "heat task stuck" software reset occurs the stack of the stuck task is recorded instead of the stack of the currently-executing task
• In laser mode a G1 command may now have up to eight S parameters to specify the laser power at uniform intervals along the move (raster clustering) ** NOTE: this has not been tested yet **
• The maximum length of a string expression is increased from 100 to 256 characters. Filenames are still limited to 120 characters.
• Firmware version numbers now conform to Semver 2.0.0 but we are not following the Semver standard for major version number increments on breaking changes.
• [Duet 3 MB6HC] [Duet 3 MB6XD] [Duet 2] [Duet Maestro] PWM resolution when using outputs connected to the PWM peripheral is increased

Object model changes:

• Added move.keepout which is the list of keepout zones
• Removed move.workspaceNumber
• Removed directories.scans

Bug fixes:

• M3 and M4 commands to change the speed of a spindle that is not used by the active tool were sometimes ignored
• M302 P1 did not allow cold extrusion/retraction
• M587.2 did not return the correct authentication values
• M587.2 returned truncated SSIDs
• M587.2 did not always return the complete list of access points found
• M598 did not sync motion systems and only released axes owned by the currently-active motion system
• while-loops did not return to the correct loop starting position if the macro file used CRLF line endings
• Spurious filament monitor events from expansion boards were sometimes generated when RRF started

Fixes for bugs also in RRF 3.4.5:

• M28 removed leading spaces and tabs
• M669 with a S or T parameter that was not followed by a digit caused the firmware to reset
• If a G31 command had two T (temperature coefficient) parameters but the first one was zero, then G31 with no parameters or with just a K parameter did not report either of them
• If a GCode command had a bad parameter then movement might be locked (e.g. after sending M593 P"mzv" F"40") until another command was sent from the same channel
• When estimating the print time remaining based on a previous simulation, RRF did not allow for heating up time while executing M109

RepRapFirmware 3.5.0beta2

Breaking changes since 3.5beta1:

• If the min or max function was called with a single operand, in previous versions that operand was always returned regardless of its type. Calling min or max with a single operand is now allowed only if the operand is a non-empty array of numeric values, and it returns the minimum or maximum element in the array.
• Previously, unless M564 was used to ignore machine limits, all axis limits were enforced on all G0 and G1 moves. This sometimes caused a problem on the next move if an axis limit was changed when the axis coordinate was outside the new limit. Axis limits are now enforced only for those axes that were mentioned in the G0 or G1 move.
• The default maximum accelerations were very conservative by modern standards so they have been increased. Likewise the default maximum Z speed has been increased and the default Z steps/mm has been reduced. These changes will only affect you if you do not define the maximum speeds, accelerations and steps/mm for all axes using M201, M203 and M92.
• Default M201.1 values (accelerations for stall homing and Z probing moves) are now set. If you do not use the M201.1 command to change these values then acceleration during bed probing and stall homing moves may be lower than before.

New features and other changed behaviour since 3.5beta1:

• M150 with parameter F1 no longer waits for motion to stop when using a bit-banged port
• M291 messages are now queued. When a M291 command is executed the new message is added to the end of the queue, and any non-blocking messages already in the queue have their timeouts reduced to 1 second. If the queue is already full then the oldest non-blocking message is cancelled, or if there are no non-blocking messages in the queue, the oldest message is cancelled. The queue length is currently 8 messages.
• M425 backlash compensation is supported experimentally
• M500 P10 now saves the tool offsets to 3 decimal places instead of 2
• M569.7 now supports S parameter to specify the delay between engaging the brake and disabling the driver
• [Duet 3 MB6HC] [Duet 3 EXP3HC] [Duet 3 EXP1HCL] M569.7 now allows brake voltage to be selected
• [Duet 3] M599 (keepout zone) is now supported. Important: this has not yet been fully tested, especially for correct behaviour with G2/G3 moves.
• [Duet 3] Increased the maximum open file count from 10 to 20
• Recognises filament usage string in GCode files generated by S3D version 5
• Functions min() and max() can now be applied to a single parameter of array type
• Added function "vector(numElements, elementValue)"
• The 'set' command can now be used to change the values of individual elements of an array variable
• Added option for the echo command to append to a file without adding a terminating newline, echo >>>filename ...
• If any error messages are generated during startup when processing config.g, the first such message is saved along with its line number and made available via the object model and M122
• SPI-connected LIS3DH/LIS3DSH accelerometers are now supported experimentally on RPi Pico and other RP2040-based boards
• SPI-connected temperature sensors are now supported experimentally on RPi Pico and other RP2040-based boards
• TMC2209 drivers are now supported experimentally on RPi Pico and other RP2040-based boards
• [Duet 3] When running a job from file, 'echo', 'global' and 'set global....' commands are only executed by the currently-selected motion system
• [Duet 3 MB6HC] [Duet 3 MB6XD] The maximum number of axes has been increased to 30 experimentally. The maximum number of axes+extruders has been increased to 32. Axis letters XYZUVWABCD and a..z may be used when using these boards.
• [Duet 3 MB6XD] Added detection of the forthcoming MB6XD 1.01 board
• [Duet 3] Added MQTT publisher support. This is still work in progress. It is currently tested on the Duet 3 Mini WiFi and the WiFi module must be running version 2.1beta3 or later of DuetWiFiServer. It may also work on the Duet 3 MB6HC 1.02 board with the optional WiFi module but this has not been tested. It is not yet implemented on Ethernet interfaces.
• [Duet 3 EXP1HCL] [Duet 3 M23CL] Added experimental velocity feedforward parameter V to the existing M569.1 PID parameters. The default value is zero. Note, the standard step tuning move does not use this parameter, therefore if you use a nonzero value then you need to use a regular G1 move instead when you perform PID tuning.

Internal changes:

• Upgraded FatFs from version 0.14b to 0.15 patch 2
• [Duet 2] [Duet 3 MB6HC] [Duet 3 MB6XD] Freed up 216 bytes of RAM

Object model changes:

• Added Boolean field inputs[].active which is true if the input is is in active mode i.e. executing commands, false if it is assigned to a motion system other than the current one. This will always be true except for the File and File2 inputs.
• Added Boolean field state.thisActive which is shorthand for inputs[state.thisInput].active
• Added float field move.axes[].backlash which is the configured backlash compensation for the corresponding motor in mm
• Added integer field move.backlashFactor which is the configured M425 S parameter
• Added integer field state.gpOut[].freq which is the configured PWM frequency of the port
• Added state.startupError which is either null or contains fields message (string), file (string) and line (integer) corresponding to the first error message that was generated during startup.
• Increased the reported precision of state.gpOut[].pwm from 2 to 3 decimal places

Fixes for bugs new in RRF 3.5beta1:

• Fixed crash or strange behaviour after using G32 for true bed levelling
• "echo move[N].drivers[M]" gave an array out of bound error when M was nonzero but less than the number of drivers for axis N
• "echo move[N].drivers" reported incorrect values
• When a macro completed the system waited for motion to stop. This was a particular problem if daemon.g regularly called a macro.
• The extruder position reported by DWC and in the object model was always zero
• New M291 messages did not overwrite older ones (see changes to M291 listed earlier)
• Fixed memory leak when nested arrays were used
• Axes whose names were lowercase letters could not be created
• [Duet 3] Updating a Duet 3 main board used as an expansion board over CAN didn't work
• [Duet 3] When the main board in a CAN-connected system was reset, any other main board used as an expansion board lost its CAN connection
• [Duet 3] The reported machine coordinates were always taken from motion system 0 even when motion system 1 was active
• [Duet 3] On tool changers, if the tpre or tpost file used M208 to change an axis limit when the tool was outside that axis limit, and the next move referred to rotational axes only but caused no motion (e.g. a tool coupler move when the coupler was already in the required position) then incorrect motion could occur on the move after that.

Fixes to bugs also present in RRF 3.4.5:

• When starting a print, DWC and PanelDue did not always update the displayed information for that file, depending on the file contents
• The reduced accelerations set by M201.1 or their default values were used when executing special moves even if they were higher than the normal M201 values
• When running a job or macro file that used CRLF as the line ending, the line number was incremented twice per line
• When M500 P10 was run the G10 tool offset lines added to config-override.g has spurious 0.0 values at the end
• When two M569.5 commands were sent in quick succession so that the first one was still in progress when the second one was sent, if the rate of data collection was high then the board would sometimes reset with a memory protection fault
• If temperature sensors were added or removed while an extruding move was being started, a reset might occur
• If temperature sensors were added or removed while Z probing and a trigger height temperature coefficient was in use, a reset might occur
• If a FTP client executed a CHUP command that moved to the root directory, a subsequent PWD command returned path "" instead of "/"
• If M574 commands were executed frequency then the Duet would occasionally reset with a "stuck in spin loop" software reset code
• [Duet 3] When a Duet 3 main board was used as an expansion board, with some print files a memory leak would occur which could eventually cause the board to reset with an Out Of Memory error recorded in the M122 software reset data
• [Duet 3 MB6HC - version 1.02 with WiFi module] If M552 was used to put the WiFi module into idle or disabled mode, any existing Ethernet HTTP sessions were disconnected temporarily
• [Duet 3 MB6HC - version 1.02 with WiFi module] If the WiFi module had never been enabled then M112 displayed uninitialised values for the WiFi error counts
• [Duet 3 MB6HC - version 1.02 with WiFi module] If the reset button was used to reset the Duet then the WiFi module was not reset
• [Duet 3] The B parameter passed to filament-error.g when a filament event occurred was always zero
• [Duet 3] M952 didn't accept parameter B0

RepRapFirmware 3.5.0beta1

Breaking changes since 3.4.5:

• M667 is no longer supported. To select CoreXY mode use M669 K1 instead.
• The use of M1 to end a job is deprecated. The M1 command no longer runs file sleep.g, instead it runs stop.g like M0. In future we expect to change the behaviour of M1 to be in line with the NIST standard.
• It is no longer acceptable to use the G1 S parameter instead of the H parameter to indicate a homing move or other special move. In previous versions the S parameter was accepted when not in laser mode but a warning message was generated.
• When a print is cancelled, cancel.g is run regardless of whether all axes are flagged as having been homed. You may need to modify your cancel.g file to check whether axes have been homed before trying to move them.
• The error descriptions in heater fault event messages and in the response when M308 is used to query a sensor have been replaced by shorter error codes, e.g. "short-circuit in sensor" has been replaced by "shortCircuit" and "success" has been replaced by "ok". These error descriptions are now the same as in new object model value sensors.analog[].state.
• [Duet 2] Scanner support has been removed. It was only enabled in the Duet 2 build and as far as we know, it was no longer used.
• [Duet 2] Rotary delta kinematics is no longer supported. This change has been made to free up flash memory space for new features.
• [Duet 3 MB6HC] [Duet 3 MB6XD] Lowercase letters ghijkl may no longer be used as axis letters. The complete set of available axis letters is now XYZUVWABCDabcdef.
• [Duet 3 EXP1HCL] The M569.1 configuration parameters have changed. For quadrature encoders, the C parameter is now the number of quadrature pulses per revolution. The new S parameter is the number of full steps per revolution, default 200.
• [Duet 3 EXP1HCL] Default warning and error thresholds are now set for generating events when the driver fails to maintain position

Known/suspected issues:

• M303 heater tuning can no longer be cancelled by sending M0
• [Duet 3] Updating a Duet 3 main board used as an expansion board by uploading the file and/or sending M997 to the actual main board does not work in this release
• [Duet 3 EXP1HCL] When collecting data using the Closed Loop Tuning plugin using the "As fast as possible" setting you are more likely to see Data Lost errors in the file than before. We believe this is because the EXP1HCL firmware is now more efficient and "as fast as possible" is faster than before. If you experience this issue, try selecting e.g. 10000 or 5000 samples/sec instead of "as fast as possible".
• [Duet 2 WiFi] [Duet 3 Mini WiFi] [Duet 3 MB6HC - version 1.02 with prototype WiFi module] If using DuetWiFiServer 2.1beta2 the report generated by the new M582.2 command loses some initial characters of the SSID
• [Duet 2 WiFi] [Duet 3 Mini WiFi] [Duet 3 MB6HC - version 1.02 with prototype WiFi module] If using DuetWiFiServer 2.1beta2 then when the wifi module is running in station mode the RSSI is always reported as 0
• [Duet 3] The support for multiple motion systems in this release is EXPERIMENTAL and the specification is likely to be changed to better support user requirements. If you wish to use, please be careful (e.g. reduce motor currents to mitigate any unexpected behaviour) and report your experience to us on the forum.

New features and other changed behaviour since 3.4.5:

• G69 command now waits for all motion to stop before being executed
• G73 (inverse time mode) and G74 (normal feed rate mode) commands are now supported experimentally
• M0 no longer sets drivers to idle current immediately
• M2 (end job) command is now supported. It behaves the same as M0.
• M17 (enable drivers) command now waits for all motion to stop before being executed
• M18 (disable drivers) command now activates (i.e. removes power to) any associated motor brake(s) by 200ms before turning the motor(s) off. We intend to make this time configurable in future.
• M22 now checks whether there are any open files on the SD card and doesn't unmount it if there are
• M81 command now supports the new D (delay) parameter
• M200 command now supports the new S parameter so that volumetric extrusion can now be enabled/disabled without changing the filament diameter, and vice versa
• M291 command now supports new message box modes 4, 5, 6 and 7. These are supported by DWC but not yet by PanelDue.
• M303 command now has an optional Q (Quiet) parameter to suppress the suggestions to edit config.g or run M500 when it finishes. Use this if you run M303 inside a macro that saves the new parameters automatically.
• M570 command supports a new R parameter, which is the maximum number of consecutive bad temperature readings allowed before a heater fault is triggered
• M582 command can now set triggers pending unconditionally using the new S parameter
• When a print file completes normally then file stop.g is run automatically even if the print file did not end with a M0 command
• Array-valued user variables are now supported
• If an array-valued item is used as an argument to the echo command, the array elements are now displayed inside [ ] instead of displaying [array].
• New function fileexists(filename) is now available in conditional GCode
• The Duet3Expansion project supports an experimental build for the RPi Pico. This backed up by builds of the CoreN2G, RRFLibraries, CANlib and FreeRTOS projects for the RP2040 processor.
• The Duet3Expansion project supports a build for the prototype Duet3D closed loop motors (M23CL)
• In menu files for 12864 displays the V (visibility) parameter in any menu item may now be an object model expression enclosed in { } returning a Boolean value, as an alternative to one of the existing numeric codes. The N (item number) parameter in a "value" menu item may now be an object model expression enclosed in { } representing the value to be displayed, as an alternative to one of the existing item codes.
• [Hangprinter kinematics] Various improvements have been made
• [Duet 3 MB6HC] [Duet 3 MB6XD] [Duet 3 Mini] Multiple motion systems are supported. See https://docs.duet3d.com/en/User_manual/RepRapFirmware/Multiple_motion_systems. Caution: this feature is experimental and may not be fully working in this release.
• [Duet 3 MB6HC] [Duet 3 MB6XD] [Duet 3 Mini] [EXP3HC] [SAMMYC21] BME280 temperature/pressure/humidity sensors connected via SPI are now supported
• [Duet 3 MB6HC] [Duet 3 MB6XD] [Duet 3 Mini] New subfunction S4 of G29 allows selective probing for a height map
• [Duet 3 MB6HC - version 1.02] Experimental support for add-on WiFi module has been added
• [Duet 3 EXP1HCL] Duet3D prototype magnetic shaft encoders are now supported
• [Duet 3 EXP1HCL] Linear quadrature encoders are now supported. The motor must also have a Duet 3 magnetic shaft encoder.
• [Duet 2 WiFi] [Duet 3 Mini WiFi] [Duet 3 MB6HC - version 1.02 with prototype WiFi module] Added functions M587.1 and M587.2 to scan for and list available WiFi networks (needs WiFi firmware version 2.x).

Object model changes since 3.4.3:

• The machine coordinates returned in the object model are now updated during moves. The maximum update rate is once every 200ms.
• Added integer field: inputs[].motionSystem (only on builds that support multiple motion systems)
• Added integer field: inputs[].selectedPlane
• Added Boolean field: inputs[].inverseTimeMode
• Added floating point field: move.extruders[].filamentDiameter
• Added floating point fields: heat.heaters[].maxHeatingFaultTime and heat.heaters[].maxTempExcursion
• Added integer field: heat.heaters[].maxBadReadings
• Added integer array field: fans[].sensors[]
• Added floating point fields: spindles[].idlePwm, spindles[].minPwm and spindles[].maxPwm
• Added floating point field move.currentMove.extrusionRate (returns the current total extrusion rate in mm/sec)
• Added text field sensors.analog[].state (returns "ok" if the sensor is working, otherwise a short description e.g. "openCircuit"
• Added integer field job.lastWarmUpDuration
• Field fans[].heaters[] is now flagged as obsolete. Use fans[].sensors[] instead.
• Removed obsolete fields: job.firstLayerDuration and job.timesLeft.layer

Internal changes:

• Auto detection of WiFi module type in WiFiFirmwareUploader. This does not include selecting the correct WiFi firmware binary automatically.

Bug fixes since 3.4.3:

• If only one of the X any Y axes had been homed and a normal move along that axis was commanded when nonzero G68 coordinate rotation was in effect, the move should have been rejected because it involved moving the un-homed axes
• A rr_model or M409 object model query with a key of the form "global.myvar" reported on all global variables, not just the requested one
• A rr_model or M409 object model query ignored an attempt to select a member from or index into a value of a primitive type. For example, a request for "state.currentTool[0]" returned the value of state.currentTool instead of null.
• It was already prohibited to assign an object value to a variable using the set command, however the check for creating a variable with an initial object value was missing. If you did create such a global variable (e.g. "global a1=move.axes[1]") then DWC looped trying to connect because RRF returned bad JSON.
• When evaluating expressions, #global.xxx where the value of xxx is a string returned the string instead of the length. #(global.xxx) worked correctly.
• When a job was paused or power was lost and a tool spindle was turning, the resurrect.g file did not include the commands needed to restore the spindle speed and direction
• [Duet 3 Mini] Under certain conditions the USB port could become unresponsive, for example if M575 P0 S0 was used to reinitialise it
• [Duet 3] If several M569.5 closed loop tuning commands were issued in rapid succession, the Duet might reset
• [Duet 3 + SBC] If the SBC connection was reset while the Duet was attempting to send data to it for writing to a file (e.g. closed loop tuning or accelerometer data) then the Duet might reset due to a Hard Fault
• [Duet 3 EXP1HCL] The M569.2 command to read stepper driver registers was not supported

RepRapFirmware 3.4.0 post beta7

These are the changes between 3.4.0beta7 and 3.4.0rc1

Upgrade notes:

• If you are upgrading from 3.4.0beta7 and you are using event handler macro files, note the name changes to the macro files (see below)
• [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 3.4.0rc2. Ports io2.out and io3.out do work correctly (but note that io3.out is shared with the 12864 display backlight control).
• [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 MB6XD in standalone mode] If you are upgrading a prototype MB6XD board running in standalone mode then you will need to upload file Duet3_SDiap32_MB6XD.bin as well as Duet3Firmware_MB6XD.bin

New features and changed behaviour:

• The macro files run after events are now heater-fault.g, filament-error.g (as in RRF 3.3), driver-error.g, driver-warning.g and driver-stall.g instead of these names with the '-' character replaced by '_'
• Hobby servos can now be used with user-settable refresh frequencies (previously, only 50Hz was supported)
• The tolerance for the actual vs. expected heating rate of bed and chamber heaters has been widened further, to avoid spurious heater faults on bed heaters with poor coupling between the thermistor and the thermal mass of the bed
• The response from M36 now includes details of any PNG- or QOI-encoded thumbnails found near the start of the GCode file
• The M36 command has been extended to provide information about thumbnail images embedded in the GCode file, and a new command M36.1 has been provided to retrieve thumbnail data. Similarly, HTTP command rr_fileinfo has been extended and rr_thumbnail has been added.
• 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.
• M573 is no longer supported. You can read a heater average PWM from the object model instead.
• [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 2 WiFi][Duet 3 Mini WiFi] Added support for additional ESP reset codes in preparation for new WiFi module code
• [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 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 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 Mini] The maximum number of bed and chamber heaters has been increased to 4 of each (previously was 2 of each)
• [Duet 3 MB6XD prototypes] Support for these prototype boards has been added

Object model changes:

• 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.
• Fields move.limitAxes and move.noMovesBeforeHoming are added
• Field job.numLayers is added (zero if the total number of layers it not known)
• Array job.thumbnails is added

Bug fixes:

• 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
• When generating steps for an extruder the first 2, 4 or 8 microsteps were sometimes generated too rapidly, depending on the fraction of a microstep that was overdue from the previous move
• If a heater was used and then turned off, and the heater temperature then fell to below 25C, then the heater might fail to turn on again, resulting in a heater fault
• 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
• 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
• [Duet 3 with expansion/tool boards] The M280 command did not work with ports on expansion boards (new bug in 3.4.0beta7)
• [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
• [Duet 3 MB6HC] and [Duet 3 Mini Ethernet] File uploads over Ethernet sometimes failed with CRC errors
• [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 3 used as expansion board] Added support for M915 and fixed various issues

RepRapFirmware 3.4.0beta7

Upgrade notes:

• The handling of filament errors have changed. When a filament error occurs, an event is created. To handle the event, RRF runs macro file filament_error.g without appending the extruder number to the file name and without pausing the print first. The extruder number is passed as param.D along with some other parameters. If filament_error.g is not found then the print is paused (running pause.g) and the error is reported.
• The handling of driver stalls has changed. In the M915 command there is no longer a distinction between R2 and R3; both cause an event to be created when the driver stalls. To handle the event, RRF calls driver_stall.g passing the stalled local driver number in param.D and the CAN address of the board concerned in param.B. File rehome.g is no longer used. If file driver_stall.g is not found then the print is paused without running pause.g and the error is reported.
• The handling of heater faults has changed. When a heater fault occurs, an event is created. To handle the event, RRF runs macro file heater_fault.g without pausing the print first. The heater number is passed as param.D along with some other parameters. If file heater_fault.g is not found then the print is paused and the user is notified. Currently, RRF does not attempt to turn off power to the whole machine if the user does not respond to the heater fault. We plan to reinstate this or a similar function in release 3.4.0RC1.
• [Duet 3 with expansion/tool boards] Both the main board and expansion board firmware must updated to version 3.4.0beta7, otherwise some functions may not work e.g. accelerometer data collection from tool boards.
• [EXP1HCL] The Duet3Firmware-EXP1HCL.bin file is for the version 1.0 production boards, which are not widely available yet. File Duet3Firmware-EXP1HCLv0_3.bin is for the version 0.3 prototypes. If you have a version 0.3 prototype board then before updating the firmware on that board you must delete or rename Duet3Firmware-EXP1HCL.bin, and rename Duet3Firmware-EXP1HCLv0_3.bin to Duet3Firmware-EXP1HCL.bin.

New features and behaviour changes:

• The heater model now includes non-Newtonian cooling to better predict the variation of cooling rate with temperature and the maximum temperature that would be reached at continuous full power
• The algorithm used to detect a heater fault while heating up now averages the heating rate over a longer period of time, so that noise in the reading is less likely to trigger a spurious heater fault
• Increased maximum extruders to 8 on Duet 3 Mini
• The generated resurrect.g file no longer includes a T-1 P0 command. This is to aid print recovery on tool changers.
• Collecting more than 65535 accelerometer samples in a single run is now permitted
• 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
• When collecting data from EXP1HCL closed loop driver boards, some fields in the .csv file have been renamed to match changes to the plugin
• 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 it 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 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.

Object model changes:

• Fields gain, timeConstant and timeConstantFanOn of heaters[].model are removed. Fields coolingRate, coolingExp and fanCoolingRate are added.
• Field boards[].maxMotors is no longer flagged 'verbose'
• 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.

Bug fixes:

• In some circumstances the machine state was still be reported as "Changing tool" after a tool change had completed. This was a new bug in 3.4.0beta6.
• Unpredictable behaviour might occur when using a large number of mesh probe points (more than 416 points for most Duets)
• Extrusion would stop when processing a move so tiny that it would take less than 0.7 microseconds to execute
• When evaluating an expression of the form "A & B", if A was false but a subexpression within B contained an array indexing operation in which the index had an undefined value, error message "expected integer expression" was produced and execution terminated. Similarly for expressions of the form "A | B" when A was true.
• 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
• [Polar Kinematics]The code to limit speed and acceleration for polar kinematics didn't always work correctly
• If M591 S# 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.
• [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
• [Delta Kinematics] Under some conditions, incorrect tower movement occurred (new bug in RRF 3.4beta series)
• [Polar Kinematics] Fixes to polar kinematics
• [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 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 2 SBC] Height maps were not saved to file in 3.4.0beta6
• [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 + SBC] SBC file requests were not fully invalidated
• [Duet 3 MB6HC + Hangprinter Kinematics with ODrives] Fixes to the ODriver CAN interface
• [Duet 3] Duet 3 Main boards used as expansion boards did not announce themselves to the master main board, so they did not appears in the 'boards' part of the object model

RepRapFirmware 3.4.0beta6

Upgrade notes:

• Important! 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.

Known issues:

• After a tool change, the status in DWC and the object model field state.status may continue to be reported as "Changing tool"

New features and changed behaviour:

• 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).
• Input shaping types "mzv" and "zvddd" are now supported, in addition to the other types that were supported already
• 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
• M81 now accepts a C parameter, allowing a PS_ON pin to be assigned in config.g while leaving VIN power turned off
• The PS_ON pin is no longer allocated as a power control pin by default. See the upgrade notes.
• [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 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).

Object model changes:

• 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.
• 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.
• For magnetic and laser filament monitors, field filamentMonitors[].configured.allMoves is added

Bug fixes:

• Fixed typo in message "the height map was loaded when the current Z=0 datum was not determined by probing"
• Fixed issue with configuring a temperature sensor of type "thermocouple-max31856" on an expansion board (again).
• 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
• M0 when not paused always turned the heaters off even if there was a stop.g file
• 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 occurrent of spurious paused due to reported under or over extrusion.
• DWC did not report the calibration figures 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
• M669 did not report the current A and F parameters when using Polar kinematics
• Requests for ocsp-over-http were not recognised if the requested filename started with "ocsp" instead of "/ocsp"
• The default M203 maximum speeds, M201 accelerations, M566 jerk rates and M558 speeds were not set correctly (this was a new bug in 3.4beta)
• [Polar Kinematics]When using Polar kinematics the A and F parameters didn't work (this was a new bug in 3.4beta)
• [Polar Kinematics]When using Polar kinematics, XY movement was not permitted until Z had been homed
• [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 3 MB6HC] Fixed stall detection sensitivity change
• [Duet 3 MB6HC] 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 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.

RepRapFirmware 3.4.0beta5

Known issues:

• [Duet 3 MB6HC] The stall detection sensitivity has changed and it is harder to find settings that work. If you use stall homing with the MB6HC then you may wish to wait for the next beta.

Upgrade notes:

• If you upgrade tool or expansion board firmware without also upgrading the main board firmware, then the tool or expansion board will not appear in the object model in the "boards" array
• [Duet 3 in standalone mode] The default MAC address will change in this release. This means that your router is likely to assign it a different IP address from the previous one. If you have a DHCP address reservation for the Duet configured in your router, you will need to update it for the new MAC address.
• [EXP1HCL] You will need to re-tune your PID parameters. High P and D values are more likely to cause oscillation than before.

New features and changed behaviour:

• [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)
• M280 commands to reset babystepping to absolute values (e.g. M290 R0 Z0.0) are once again permitted even when the axes concerned are flagged as not having been homed; however if the axes have not been homed then no movement will be performed
• 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
• [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.
• [EXP1HCL] The M569.5 command may now use higher sample rates. If using a high sample rate results in the sample buffer overflowing then sampling will be stopped at that point, data already collected will be written to the file, followed by "Buffer overflowed" on a new line.
• [EXP1HCL] When the M569.5 commands includes a V parameter, the motor will be enabled automatically, as for the M569.6 command
• [EXP1HCL] When executing a tuning move there is now a 100ms delay before starting the move, to allow the motor brake to be released and the driver to be enabled
• [EXP1HCL] The number of tuning moves has been reduced to simplify tuning. V1 does basic tuning (polarity detection, zeroing for relative encoders, and CPR checking) and is needed after every power on regardless of the encoder type. It moves up to 4 full steps in either direction and returns to the original position. V2 performs calibration of magnetic motor angle sensors. It performs up to two complete motor resolutions. If successful then the calibration data is stored in non-volatile memory so that it need not be run again. No other tuning moves are supported at this time.
• [EXP1HCL] In closed loop mode the minimum holding current in percent is now set by the M569.1 H parameter. In open loop mode, M917 is used as before.

Object model changes:

• 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.
• Expansion boards now have separate firmwareVersion and firmwareDate properties in the boards[] object. Previously, firmwareVersion held both the version and the build date. Both the main boards and the expansion boards need to run firmware 3.4.0beta5 for this to work correctly.

Internal changes:

• FatFs has been upgraded from version 0.13c to 0.14b

Bug fixes:

• [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 2] If a TMC2660 driver was removed from the Duet or Duex then none of the TMC2660 drivers would start up
• [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 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.
• [EXP1HCL] When collecting data from the closed loop motion controller, the last variable that was requested to be collected was not collected properly
• [EXP1HCL] Tuning moves were executed too fast for some types of stepper motor
• [EXP3HC] The buffer used to store the sensor type name in a M308 command was too short to accommodate "thermocouple-max31855"

RepRapFirmware 3.4.0beta4

Known issues:

• [Duet + SBC] If a print is paused then in many cases the print will restart from the start of the file instead of from the paused position

New features and changed behaviour:

• When upgrading the main board firmware, if the IAP file is not found in /firmware then RRF looks for it in /sys
• M80 now has an optional C parameter allowing the PS_ON port and polarity to be changed
• 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
• M309 (set/report heater feedforward) is supported
• 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. Previoualy 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) is no longer permitted on an axis that has not 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

Object model changes:

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

Internal changes:

• 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.
• [Duet + SBCe] Filament handling is now done by RRF, not by the SBC

Bug fixes:

• [Delta Kinematics]The step calculation for delta printers occasionally resulted in one microstep being taken in the wrong direction, resulting in leaning prints
• Motor idle timeout did not work
• M42 Jn C"nil" didn't release the port if it was on an expansion board (the fix is in the expansion board firmware)
• 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.
• Bed levelling (leadscrew adjustment) moves were delayed until a normal move command was executed
• String parameters to macros were sometimes rendered invalid
• When a line of received GCode included a line number and checksum, RRF ignored a bad checksum
• When a GCode input channel was set up to require checksums (e.g. as is normal for a PanelDue port), if the checksum was missing then the line was executed in any case
• Heater fault detection was too sensitive during the heating up phase
• When running tuning on a prototype EXP1HCL closed loop board, the processor was stuck while waiting for a response, and if tuning took more than 20 seconds then the main board would reset with a "Stuck in spin loop" error

RepRapFirmware 3.4.0beta3

New features and changed behaviour:

• Input shaping is supported experimentally on the Duet Maestro
• The ACT LED on the Duet3 Mini is supported
• The option to append a re-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 EXP1HCL closed loop driver board is now supported
• The maximum number of fans supported on Duet 3 systems is now 20

Object model changes:

• Added field canReverse to Spindle
• Added fields percentCurrent and percentStstCurrent to move.axes[] and move.extruders[]
• Heater PWM is now reported to 3 decimal places (was 2)
• 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.

Bug fixes:

• 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
• [Duet 3 expansion/tool boards] If a PT1000 sensor was configured but not connected, RRF reported a crazy temperature
• [Duet 3 tool boards] A small number of tool boards gave obviously inaccurate temperature readings when running tool board firmware 3.4.0beta2

RepRapFirmware 3.4.0beta2

Upgrade notes:

• 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. For example, M92 E{var.e1}:400:{var.e3} will no longer work and must be replaced by M92 E{var.e1,400,var.e3}.
• The H parameter of the M0 and M1 commands has been removed. Heaters will always be turned off when these commands are executed; except that if M1 is used to cancel a print that is paused and file cancel.g exists, cancel.g will be run and heaters will remain on unless cancel.g turned them off. Previously, M0 H1 or M1 H1 would leave heaters turned on.

New features and behaviour changes:

• Input shaping types ZVD, ZVDD, EI2 and EI3 are supported, except in the Duet Maestro build. See the M593 command in the Duet3D GCodes wiki page. DAA is no longer supported except in the Duet Maestro build.
• 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
• [Duet + SBC] Resume after power fail and resume after pause/power down are now supported
• [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 (needs new expansion/tool board firmware too)

Object model changes:

• 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.
• Added field tools[N].isRetracted
• The Z offset of a Z probe is now reported as the negative of the trigger height instead of always being zero

Bug fixes:

• 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.
• [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
• [Input shaping branch only] Several bugs related to input shaping have been fixed

RepRapFirmware 3.4.0beta1

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 is also present in release 3.2.x and 3.3.
• 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 bug is also present 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. This bug is also present in release 3.3.
• Sending a M956 command that refers to an accelerometer on a CAN-connected board via the Pi (e.g.rom DWC) does not work and report that the accelerometer was not found. Workaround: send the command to the Duet from a PanelDue or via USB instead. [This will need to be fixed in DSF]

Upgrade notes and behaviour changes:

• [Duet + SBC] This version of RepRapFirmware requires Duet Software Framework version 3.4.0beta1
• 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.
• 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.

New features and changed behaviour:

• Collection of accelerometer data is now supported in SBC mode
• DHT11 temperature/humidity sensors are no longer supported
• DHT21 and DHT22 sensors now use less RAM
• The first layer height of the file being printed is no longer reported in the object model or by M408
• The number of layers of the file being printed is no longer reported in the object model
• 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
• Added M956 F"filename" parameter
• [Duet 2] Increased maximum number of RGB NeoPixel LEDs on Duet 2 WiFi/Ethernet from 60 to 80
• 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
• [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.

Object model changes:

• Field heaters[].avgPwm is added
• Field heaters[].model is no longer flagged 'verbose'
• Fields job.file.firstLayerHeight and job.file.numLayers are removed

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

RepRapFirmware 3.3beta3

Upgrade notes:

• 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
• 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.
• 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.
• [Duet 3 Mini] Immediately after upgrading to this release you may get 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.

New features:

• 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).
• Global variables are now included in the object model reported by rr_model and by M409
• 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 on Duet 3 and Duet 3 Mini
• [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.
• Added M569.2 which allows any TMC22xx or TMC51xx stepper driver register to be read or written
• The delay before trying to open the daemon.g file has been increased from 1 to 10 seconds, except for the first time.
• [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 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) or measuring axis length using G1 H3 moves when the motors concerned are connected to expansion boards.

Internal changes:

• A separate task is now used to finalise moves for execution
• Data returned by TMC2209 drivers is now CRC checked

Bug fixes:

• M150 X parameter was broken in 3.3beta2
• M954 command was broken in 3.3beta2
• When using attached SBC, in 3.3beta2 if an expression returned a string then under some conditions the string would not be returned and error message "unsupported type code 13" would be generated
• 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 M117 was used when moves were queued, the message could be truncated and an "Invalid command" error message could be reported (new bug in 3.3beta)
• 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
• 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 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 Tool Board] It was not possible to update the bootloader over CAN (new bug in 3.3beta2)
• [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
• [SAMMYC21] The STEP output for an external stepper driver did not work in 3.3beta2

RepRapFirmware 3.3beta2

Upgrade notes:

• 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 wiki for details.
• 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.
• G31 Cnnn (temperature coefficient) 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 been changed, details TBA
• The object model for resonance compensation (move.daa) has changed, details TBA
• 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.
• 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 printer 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 with expansion/tool boards] If you are upgrading from 3.3beta1 then you must upgrade the main board firmware first, then the expansion board firmware. This is because the 3.3beta1 main bo0ard firmware fetches expansion board firmware from /sys instead of /firmware.
• Caution! There have been some major internal changes in this release, so the risk of new bugs is higher than usual. Check basic operation of your machine before starting a print, and we suggest you do not leave your machine unattended during the first few prints. If your machine starts behaving strangely, if possible get a M122 report before rebooting it.

Known issues new in this release:

• M150 commands with X parameter are rejected, therefore you can only use the default LED strip type (NeoPixel, which is X1)
• M954 command does not work because the A parameter is rejected
• When using attached SBC, if an expression returned a string then under some conditions the string will not be returned and error message "unsupported type code 13" is generated

New features and changed behaviour:

• 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. These commands are not yet available in SBC mode. It is intended to report global variables in the object model, but this is currently not done. Also it is not yet possible to query whether a particular variable or parameter exists.
• 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.
• Spindles can now be assigned to an arbitrary number of tools and each tool maintains its own spindle RPM value.
• 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, but not yet displayed by the current PanelDueFirmware.
• Estimated print completion time based on layer progress has been removed (see under Upgrade notes)
• M408 and rr_status no longer report first layer duration or first layer height
• Maximum step rates on Duet 2 WiFi/Ethernet, Duet 3 MB6HC, Duet 3 Mini and EXP3HC 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 and Fusion 360 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

Object model changes:

• 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
• 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:

• 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
• Some commands (e.g. M950) did not accept an expression when reading a pin name parameter
• When waiting for a heater to reach temperature with M109 there were no more updates sent to PanelDue
• [Duet Maestro] The encoder on a 12864 display didn't work [new bug in 3.3beta1]
• [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. In 3.3beta 1 these were indicated by CAN send timeouts in the main board M122 report and nonzero CAN 'oos' error counts in the expansion board M122 report
• [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 most instances of send timeouts on Duet 3 and 3 Mini main 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

RepRapFirmware 3.3beta1

Changes listed here are since version 3.2.2. Changes that were originally listed here but were back-ported to release 3.2.2 are no longer described here.

Compatible firmware versions (all the same as in the RepRapFirmware 3.2.2 release):

• Duet Web Control 3.2.2
• Duet Software Framework 3.2.2 (for users with attached Single Board Computer)
• DuetWiFiServer 1.25

Upgrade notes:

• All extruders must be declared explicitly using M584. In previous firmware versions, one default extruder was assign to driver 3.
• 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.3beta1 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.
• [Duet 3 with expansion/tool boards] You must update the expansion and/or tool board firmware to 3.3beta1 also, otherwise movement and some other functions will not work. If you accidentally end up with firmware 3.3beta 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.
• For Duet 2, Duet 3 MB6HC and Duet Maestro, the hardware abstraction layer has been switched from CoreNG to CoreN2G. This is a major change, so there is a greater than usual chance that something has stopped working, e.g. an input or output pin might fail to work in a particular mode.

New features:

• M17 is implemented
• G17, G18 and G19 are now supported. Please test G18 and G19 carefully before using for real in CNC applications!
• Print time in GCode files sliced by IdeaMaker is now recognised
• 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 2] When using extended step timings (M569 T parameter), maximum step pulse rates are improved a little
• [Duet 3 Mini] M954 is partially implemented. A Duet 3 Mini used as an expansion board 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] M122 now reports the peak CAN time sync message transmit delay
• [Duet 3 expansion/tool boards] Heater tuning is now implemented (M303) along with heater feedforward
• [Duet 3 with expansion/tool boards] Improved the accuracy of CAN clock synchronisation between main and expansion boards
• [Duet 3 expansion/tool boards] Increased maximum step rates on on tool and expansion boards, especially on EXP1XD 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.
• [Duet 3 expansion/tool boards] M122 now reports CAN clock sync jitter, peak receive delay, steps commanded and steps generated.
• [SAMMYC21] The sample firmware for SAMMYC21 now sends a diagnostic report to the USB port if character D is received from the USB port

Bug fixes:

• 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 3 expansion/tool boards] Under certain conditions, moves could be omitted. We have only been able to reproduce this when using high step pulse rates.
• [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 + SBC] It was not possible to update PaneDue firmware using M997 S4

RepRapFirmware 3.01-beta3

Recommended compatible firmware:

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

Upgrade notes:

• Object model property move.meshDeviation is renamed moved.calibration.meshDeviation
• In the M409 command and the rr_model HTTP command, the maximum depth is onw specified by letter d followed by a digit string, instead of just a digit string
• See also upgrade notes for 3.01beta1

Known issues and limitations:

• The new conditional GCode commands and expressions and parameters in GCode commands will not work on Duet 3 with a Raspberry Pi or other SBC attached, until this support has been added to Duet Software Framework
• If you try to report the entire object model using M409, the response may be too long to send and you may get a null response instead. For this reason, M409 without parameters now reports only the top-level property names as if parameter F"1" was used. Use M409 with a key string to drill down into them.
• The M587 command doesn't set up the access point password correctly, resulting in "Wrong password" reports when trying to connect to the access point
• if..elif GCode meta commands with multiple elif parts sometimes give rise to error messages "'elif' did not follow 'if'"
• When G32 true bed levelling fails (for example, because the correction required exceeds the limit), the initial and final deviation are left unchanged

New features and changed behaviour:

• More object model fields have been added

Bug fixes since 3.01-beta2:

• If you tried to access a string-valued field of the object model from a GCode command or meta command, the # operator was always applied to it automatically
• If you used an object model variable beginning with g, m or t in an expression within a regular GCode command, and there was a space or tab character immediately before that letter, then after executing the command the parser would try to interpret that variable name as a new command, resulting in an error message
• On Duet 3 if you executed 2 consecutive G1 H2 moves that involved only motors on expansion boards, the firmware crashed with a memory protection fault
• A fan that hadn't explicitly been configured using M106 with some parameter other than P or S was reported to DWC as being non-controllable

RepRapFirmware 3.01beta2

Recommended compatible firmware:

• DuetWebControl 2.06
• DuetWiFiServer 1.23
• Duet Software Framework 1.2.3.0 (for Duet 3/Raspberry Pi users)

Upgrade notes:

• See upgrade notes for 3.01beta1

Known issues and limitations:

• If you try to access a string-values field of the object model from a GCode command or meta command, the # operator is always applied to it automatically
• The new conditional GCode commands and expressions and parameters in GCode commands will not work on Duet 3 with a Raspberry Pi or other SBC attached, until this support has been added to Duet Software Framework
• If you try to report the entire object model using M409, the response may be too long to send and you may get a null response instead. For this reason, M409 without parameters now reports only the top-level property names. Use M409 with a key string to drill down into them.

New features and changed behaviour:

• Many new object model fields have been added
• M409 now allows a number to be included in the flags field. This is the maximum depth to which the object model tree will be reported. It defaults to 1 if the key string is empty, otherwise to a large number.

Bug fixes:

• Object model properties move.initialDeviation, move.calibrationDeviation.mean and move.meshDeviation.mean were inaccessible
• Equality between floating point numbers gave the wrong result
• Function calls in GCode meta commands didn't work unless extra brackets were used
• If a GCode line was too long after stripping line numbers, leading white space and comments, the firmware restarted instead of reporting an error
• 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.

RepRapFirmware 3.01beta1

Recommended compatible firmware:

• DuetWebControl 2.06
• DuetWiFiServer 1.23
• Duet Software Framework 1.2.2 (for Duet 3/Raspberry Pi users)

Upgrade notes:

• You cannot upgrade a Duet WiFi, Ethernet or Maestro direct to this release from RRF 1.x or 2.x because the firmware binary is too large for the old IAP. You must upgrade to version 3.0 first, then from 3.0 you can upgrade to this release.
• [Duet 2] and [Duet Maestro] If upgrading a Duet 2 WiFi/Ethernet/Maestro from the 3.0 release, note that default fans are no longer created. Unless your config.g file already used M950 to create the fans explicitly, add commands M950 F0 C"fan0", M950 F1 C"fan1" and M950 F2 C"fan2" to config.g before your M106 commands. Likewise, default endstop switches are not set up, so you will need to set up X and Y endstops (and Z if needed) explicitly, using one M574 line for each, and specifying the port name. Example: M574 X1 S1 P"xstop".

Limitations:

• The new conditional GCode commands and expressions and parameters in GCode commands will not work on Duet 3 with a Raspberry Pi or other SBC attached, until this support has been added to Duet Software Framework

New features and changed behaviour:

• 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.
• M409 and a corresponding HTTP call rr_model have been added, to allow parts of the object model to be queried
• Parts of the RepRapFirmware Object Model have been implemented. Values can be retrieved from the OM within GCode command parameters, by M409, and by the new rr_model HTTP command. See https://github.com/Duet3D/RepRapFirmware/wiki/Object-Model-Documentation.
• The MakeDirectory and RenameFile local SD card functions now create the full path recursively if necessary
• 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.

Bug fixes:

• 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.0beta12

Recommended compatible firmware:

• Duet Web Control 2.0.4
• DuetWiFiServer 1.23
• DuetSoftwareFramework 1.1.0.5

Feature changes since beta 11:

• Duet 3 0.6 and 1.0: pin io8.out is no longer PWM-capable because of a resource clash. If you have connected a BLTouch to IO8, please move it to IO7 and adjust config.g accordingly.
• Duet 3 all revisions: improved the temperature reading accuracy at low temperatures for thermistors connected to the main board (typically it used to read several degrees low)
• Duet 3 all revisions: M308 L and H parameters are supported for thermistors and PT1000 sensors connected to the main board. They should only be used if you have suitable fixed resistors to use for calibration.
• DHT sensors are now supported (thanks wilriker)
• M115 P parameter is now only implemented on those builds that support multiple board types, and only when running config.g at startup
• M500 now accepts optional P10 parameter to force it to save the G10 tool offsets (thanks wilriker). It can be combined with P31 by using M500 P10:31.

Bug fixes:

• Duet 3 0.6 and 1.0: PWM output on io4.out and io5.out now works

• Duet 3 0.6 and 1.0: pin io6.out was incorrectly marked as PWM-capable

• Duet 3 all revisions: Driver 5 on main board didn't generate temperature warnings

• Duet 3 all revisions: updating expansion boards didn't work when running in standalone mode if the USB port was connected to a PC but no terminal emulator was running

• Duet 3 all revisions: the drivers are no longer shut down when VIN exceeds 29V

• In beta 11, control of BLTouch probes was unreliable because of glitches on the control output pin

• Homing sometimes didn't work, especially when endstops switches were already triggered at the start of the homing move

• M308 S# with no other parameters didn't report the sensor details Known issues:

• Duet 3 all revisions: file uploading via the local Ethernet port is unreliable (this is the case in previous firmware versions too). To guard against this, always enable CRC checking in DWC 2.0.4.

• Extruder stall detection (G1 H1 E moves) is not implemented

• Stall detection endstops don't work properly if you home multiple axes at the same time