Individual files not required - use the ChangeLogdev

5 files changed, 0 insertions, 524 deletions

diff --git a/ReleaseNotes/3.2.2.md b/ReleaseNotes/3.2.2.md
deleted file mode 100644
index 8bb51cb7..00000000
--- a/ReleaseNotes/3.2.2.md
+++ /dev/null
@@ -1,22 +0,0 @@
-Upgrading from a stable version earlier than 3.2? Please see the full changelog for previous stable versions of RRF here: https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x
-
-RepRapFirmware 3.2.2
-====================
-
-Upgrade notes: none since 3.2
-
-Bug fixes:
-- Using an external SD card could result in the firmware crashing if there was concurrent access to the Duet from DWC or another network client. [This is an old bug, however changes in firmware 3.1 and later made it much more likely to happen.]
-- If two DueX endstop inputs changed state approximately 2.2ms from each other, the second one might not be detected by the firmware. [This was a regression in 3.2]
-- The pin name string in M574 commands was truncated to 50 characters if it was longer, which was too short to allow four DueX endstop pins to be used. This has now been increased to 100 characters.
-- The M109 command caused a "Homing failed" message if it was used in a homing file and that homing file also called another macro file
-- In GCode expressions it was not possible to compare a value with character type (e.g. move.axes[nn].letter) with a string literal
-- Spurious blank lines were sometimes sent to USB and Telnet clients when the daemon.g file was used
-- If a G2 or G3 command with R parameter described an arc of exactly 180 degrees, then due to rounding error RRF might report "G2/G3: invalid combination of parameters".
-- Implemented a partial fix for G2/G3 moves on IDEX machines
-- [Duet 3 Mini] It was not possible to write to an external SD card
-- [Duet + SBC] Expressions were not supported in GCode parameters that accept an array of values. Expressions are now supported when only a single element needs to be provided.
-- [Duet 3 + expansion/tool boards] If DAA (M593) was used then motors connected to expansion or tool boards might lose steps
-- [Duet 3 + expansion/tool boards] The M591 E parameter was ignored for filament monitors connected to expansion or tool boards
-- [Duet 3 MB6HC] (regression in 3.2) DHT sensors did not work 
-- [Duet 3 MB6HC] (regression in 3.2) The minimum step pulse width time of the TMC5160 was not always met. This could lead to missed steps when high step rates were used.
diff --git a/ReleaseNotes/3.2.md b/ReleaseNotes/3.2.md
deleted file mode 100644
index 07bd529e..00000000
--- a/ReleaseNotes/3.2.md
+++ /dev/null
@@ -1,184 +0,0 @@
-Upgrading from a stable version earlier than 3.1.1? Please see the full changelog for previous stable versions of RRF here: https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x
-
-RepRapFirmware 3.2
-==================
-
-Upgrade notes (see also Object Model Changes if you use conditional GCode):
-- Default thermistor parameters for all builds of RRF3 are now: T100000 B4725 C7.06e-8. These match the thermistor used by E3D better than the old default, which had B4388 C0. In the unlikely event that your M308 line had a C parameter but no B parameter, you will need to add B4388 to get the previous behaviour.
-- If you are using object model field move.workspaceNumber in conditional GCode, you should preferably replace it by (move.workplaceNumber + 1). Note the different name, and that the new workplaceNumber is 0-based (so it can be used to index the workplaceOffsets arrays directly) whereas workspaceNumber was 1-based. We plan to remove workspaceNumber in a future release.
-- If you are using the M453 command to configure spindle motors and switch the firmware into CNC mode, you will need to change this command because the parameters have changed.
-- If you configure a Z probe using multiple M558 commands instead of a single one, you must make sure that only the first one has a P parameter. This is because M558 with a P parameter now sets default values before processing the other parameters of the M558 command.
-- In GCode commands, numeric parameters of the form "0xdddd" where dddd are hex digits are no longer supported. Use {0xdddd} instead.
-- It is no longer permitted to create a filament monitor using M591 and subsequently to use M584 to change the driver that the extruder is mapped to
-- The IAP files for this release have changed. After installing 3.2, the new IAP file will be needed next time you upgrade or downgrade the firmware. The new IAP files all have 'iap32' in the filename where it used to be 'iap', therefore they can coexist in /sys with the old IAP files.
-- The M303 heater tuning algorithm and parameters have changed. See https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M303_Run_heater_tuning.
-- The M307 heater model parameters have changed, however existing M307 commands will continue to work. See https://duet3d.dozuki.com/Wiki/Gcode?
-- When new axes are created using M584, if no R parameter is specified then the default for axes ABCD is now rotational. Use the R0 parameter if you want them to be linear.
-- [DWC] If you are running DWC in a development environment (e.g. via 'npm run serve'), use M586 C"*" or similar to permit cross-origin HTTP access or similar to permit cross-origin HTTP access
-- [Duet + SBC] The SPI protocol has changed, therefore versions of DCS prior to 3.2RC1 will be unable to communicate with RRF 3.2
-- [Duet 3 + expansion/tool boards] You must update the expansion and/or tool board firmware to version 3.2 also
-- [Duet 3 MB6HC] if using an attached DotStar LED strip then you now need to use M150 with the X parameter to specify the LED strip type. This is because the default type is now Neopixel.
-
-Known issues:
-- [Duet + SBC + 12864 display] Menu files are slow to load
-- [Duet 3 + expansion/tool boards] A small number of EXP3HC expansion boards and even fewer TOOL1LC boards take a long time to start up after power up when running 3.2 firmware. The most common symptom is that some of the configuration commands for them in config.g fail. In rare cases, the status light may remain off for some time before it starts flashing to indicate CAN sync (slow flash) or lack of sync (fast flash). As a workaround until we produce a fix that works in all cases, we recommend (1) use a G4 S1 delay command in config.g before the first command that refers to a motor or port on any expansion board, and (2) if in any doubt, run M98 P"config.g" from the console after power up and check there are no error messages.
-- [Duet 3 + expansion/tool boards] If you use DAA (M593 command) and you have any extruders connected to expansion boards then steps may be lost on the motors connected to those expansion boards. This issue is also present in previous firmware revisions and is fixed in 3.3beta firmware.
-- [Duet 3 + expansion/tool boards] When high step rates are demanded from motors connected to expansion and tool boards, the motors may get out of sync with the main board. This issue is also present in previous firmware revisions and is fixed in 3.3beta firmware.
-- [Duet 3 + expansion/tool boards] If a laser, magnetic or pulsed filament monitor is connected to an expansion or tool board, then any E parameter in the M591 command to configure it is ignored. Fixed in 3.3beta firmware.
-
-New features:
-- A default filename is no longer provided in the M559 and M560 commands, so the P parameter must always be used
-- Added L (calibration factor) parameter to laser filament monitor configuration
-- Added M584 R parameter to indicate whether newly created axes are continuous rotation axes or not
-- Added aux port diagnostics (overrun and framing errors) to M122 report
-- Any attempt to use G28 within a homing file now results in a specific error message
-- CORS headers are only sent in HTTP responses if explicitly configured via M586. The M586 command now accepts a C parameter to specify the allowed cross-origin site.
-- Default thermistor parameters for all builds of RRF3 are now T100000 B4725 C7.06e-8. These match the thermistor used by E3D better than the old defaults.
-- Drivers number of the form 0.# where # represents one or more decimal digits are now supported even on board that don't support CAN
-- Duet 3 Mini 5+ WiFi and Ethernet boards are supported (PCB revisions 0.4 and later)
-- G29 with no S parameter now runs file sys/mesh.g if it exists; otherwise it behaves like G29 S0 as before
-- If a filament error occurs, RepRapFirmware now tries to run file sys/filament-error#.g where # is the extruder number in minimum-width format; or if that file is not found then file sys/filament-error.g. If neither file is found then it falls back to running sys/pause.g.
-- If a filament monitor is configured for an extruder, and subsequently M584 is used to assign that extruder to a different driver, then the filament monitor will be deleted automatically and a warning issued
-- If a tool change is requested but changing tool would cause the Z max limit to be exceeded because of the changed tool Z offset, the tool change is now aborted
-- If the system runs out of memory, it will now reset and the Last Software Reset Reason reported by M122 will be "OutOfMemory"
-- Improved the instructions displayed when M303 heater tuning finishes
-- Increased the number of stack words displayed in the software reset data. The number of wear-levelling slots stored is reduced from 4 to 3.
-- It is no longer necessary to separate multiple G- or M-commands on a single line with a space or tab character
-- M111 supports CAN module debug
-- M118 has a new Lnnn parameter to specify at which log level the message will be logged (default: DEBUG). Using L0 will prevent a message being copied to the log file.
-- M122 for expansion and tool boards now reports the bootloader version, if available
-- M150 commands are now queued to sync them with movement commands
-- M308 S# H999 and L999 are now supported on those Duet 3 expansion/tool boards that have the required hardware support
-- M453 and M452 no longer report the new machine mode. Use M450 after these commands if you want the machine mode to be reported.
-- M486 now confirms when an object is cancelled or resumed
-- M558 with a P parameter now always creates a new Z probe object, which means that all the other M558 values are set to default values before processing the other M558 parameters
-- M571 command accepts Q as an alternative to F for the PWM frequency
-- M581 trigger condition parameter now supports a new value R2 which means trigger only if not printing from SD card
-- M584 commands are now checked for out-of-range driver numbers
-- M584 has a new S parameter which specifies whether new axes created in the command are to be treated as linear (S0) or rotational (S1) for the purpose of feedrate calculation. This is separate from the R parameter, which specifies whether new axes are rotational or not. The default is to treat linear axes as linear and rotational axes as rotational. You only need to provide the S parameter if you want to change the way that the feed rate is applied.
-- M591 may now be used to delete a filament monitor using the syntax M591 D# P0 where # is the extruder number
-- M906, M913 and M918 commands now wait for movement to stop, except when they are used in the power fail script
-- M929 now uses the S parameter to specify a logging level: 0=off (as previously no logging), 1=warn (all previous logged messages are in this category), 2=info (M117, M291, M292 and G10 fall into this category), 3=debug (everything else that generates output)
-- New M595 command is provided to allow the movement queue to be lengthened and optionally to pre-allocate DriveMovement objects
-- Numeric literals in GCode meta commands and in expressions enclosed by { } can now be in hex (0x prefix) or binary (0b prefix)
-- Previously there was a minimum reading cutoff at -5C when measuring temperatures using any kind of thermistor. That cutoff is now relaxed when using a low-resistance thermistor, e.g. with resistance 1K or 10K @25C.
-- Support for connecting the Ethernet adapter socket of Duet Ethernet to SBC instead, using a separate firmware build
-- Support for ST7567-based 12864 displays on Duet Maestro and Duet WiFi (thanks to SchmartMaker for writing the ST7567 driver code)
-- Support for ST7920-based 12864 displays on Duet WiFi/Ethernet
-- Supports PanelDue 3.2 better, in particular updating of displayed data while waiting for heating etc.
-- The M122 P102 and M122 P103 timing functions are more accurate and give more consistent results than in previous firmware versions
-- The M203 command now supports an optional S1 parameter which changes the units to mm/sec. The default is still mm/min.
-- The amount of free RAM has been increased. This should be sufficient to allow 12864 displays to be supported on Duet WiFi/Ethernet.
-- The minimum value for the P parameter of M584 is reduced from 3 to 2 so that the Z axis can be hidden
-- The number of DriveMovement objects pre-allocated is reduced to save memory. If the system runs out of DriveMovement objects, it will try to allocate new ones dynamically.
-- The order in which you use M307, M140, M141 and M143 is now immaterial
-- The parameters for M453 have changed. The frequency parameter is now Q (to match M950) instead of F. You can configure up to 3 ports to control each spindle. See https://duet3d.dozuki.com/Wiki/Gcode#Section_M453_in_RepRapFirmware_3_2_and_later.
-- The resurrect.g file now records which objects on the build plate have been cancelled
-- The speed of processing of GCodes received from USB has been improved, to match the speed of processing GCodes read from the SD card
-- Version 3 PanelDue boards (including all PanelDue 5i/7i) can now be updated from the Duet using M997 S4
-- When an unexpected software reset occurs, a stack usage check is performed and the result added to the software reset data
-- When new axes are created using M584, if no R parameter is specified then the default for axes ABCD is now rotational. Use the R0 parameter if you want them to be linear.
-- WiFi diagnostics now include the WiFi connection mode (needs DuetWiFiServer 1.25beta0)
-- Z probe trigger height second order temperature compensation is now supported. To use it, specify a 2-element array as the temperature coefficient, e.g. "M558 ... C0.01:0.0005".
-- [Duet + SBC] 12864 displays are now supported. Note, the 'files' menu item type is not supported in SBC mode.
-- [Duet + SBC] RepRapFirmware no longer goes into SBC mode if a SD card is inserted but can't be mounted, or if config.g is not found. This is to make diagnosis of SD card interface faults easier.
-- [Duet 2 Ethernet/WiFi/Maestro] Duet 2 builds now permit port names to have a "0." prefix, e.g. "0.e0heat". The "0." prefix is ignored.
-- [Duet 3 + expansion/tool boards] Expansion and tool boards can now have their bootloaders updated via CAN using the command M997 B# S3 where # is the board address. The bootloader file is Duet3Bootloader-SAME5x.bin for the EXP3HC board, Duet3Bootloader-SAMC21.bin for the other expansion boards by Duet3D, and Duet3Bootloader-SAMMYC21.bin for the Sammy-C21 development board. These files are available at https://github.com/Duet3D/Duet3Bootloader/releases.
-- [Duet 3 + expansion/tool boards] Filament monitors are now supported on Duet 3 expansion and tool boards. A filament monitor must be connected to the board that drives the extruder that it monitors.
-- [Duet 3 expansion and tool boards] Added M122 P102, P1005 and P1006 functions
-- [Duet 3 expansion and tool boards] Increased performance, in particular the maximum step rate is higher than before
-- [Duet 3 expansion and tool boards] Software reset data is now stored in NVRAM and reported by M122
-- [Duet 3 tool boards] Stepper driver diagnostics now include the PWM_AUTO register (main board diagnostics did already)
-- [Duet 3] Added support for second UART (using the IO_1 pins) on Duet 3 MB6HC. New message type (P5) added to M118 command.
-- [Duet 3] CAN diagnostics on both main and tool/expansion boards provide more data
-- [Duet 3] Default LED strip type is now Neopixel not DotStar
-- [Duet 3] M915 with just P and/or axis parameters now reports the belt speed in mm/sec that corresponds to the coolStep threshold
-- [Duet 3] Z probing is now abandoned if the probe is remote and cannot be contacted
-- [Duet Maestro and Duet 3] Added M308 S# H999 for open-circuit thermistor input calibration, and M308 S# L999 for short-circuit calibration. The calibration values are stored in non-volatile memory. See https://duet3d.dozuki.com/Wiki/Calibrating_thermistor_and_PT1000_readings.
-- [Duet Maestro] M308 L and H parameters are now supported.
-- [Duet+PanelDue] Status messages are sent to an attached PanelDue running firmware 3.2 during homing, heating tools etc.
-
-Object model changes:
-- Added calibrationFactor to the laser filament monitor object model
-- Added lastStopHeight to the Z probe object model
-- Added minRpm to the spindle object model
-- Added move.workplaceNumber to the object model. This is intended to replace move.workspaceNumber, but is 0-based instead of 1-based.
-- Added random(nn) function
-- Added state.msUpTime. This is the milliseconds part of upTime. When using the HTTP rr_model call or the M409 command, if the response includes both state.upTime and state.msUpTime then these two values both relate to the same instant when the command started searching the object model.
-- Added temperatureCoefficients array to the Z probe object model. For backwards compatibility, temperatureCoefficient is still supported for the time being and is equivalent to temperatureCoefficients[0]. We plan to remove temperatureCoefficient in a future release.
-- All types of filament monitors have a new field "status". The value is one of "noMonitor", "ok", "noDataReceived", "noFilament", "tooLittleMovement", "tooMuchMovement", "sensorError".
-- Field "filamentPresent" is removed from those types of filament monitor that previously supported it. Use "status" instead.
-- Field "move.axes[].homed" is no longer flagged live, and it now remains the true homed status during a simulation
-- Field "supports12864" in boards[0] has been renamed to "supportsDirectDisplay"
-- Laser, rotating magnet and pulsed filament still support the "calibrated" fields, but only for filament monitors connected to the main board
-- Spindle current/configured/max RPM were being output to 7 decimal places in object model queries. Now they are reported as integers.
-- Support DateTime - DateTime, DateTime + int, DateTime - int
-- Support T{expression} commands
-- Support comparing a value of any type that has no literals (DateTime, IPAddress, MAC address, DriverID) with a string
-- Variable boards[n] for expansion boards now includes the maxMotors value
-
-Bug fixes:
-- A M591 command with the C parameter not followed by a port name string caused the firmware to reset
-- A layer change was detected incorrectly if a travel move at an unusual height included retraction
-- After updating PanelDue firmware with M997 S4 the PanelDue did not always reset automatically
-- At the very end of a print job, RRF sometimes briefly reported a bad file position, which caused DWC to report a very high % completed
-- Duet 3 Mini only: certain types of error accessing the SD card would cause the firmware to reset due to "Stuck in spin loop".
-- Feed rate calculations did not confirm to the NIST standard when the Z axis and one or more rotational axes were moving, but not X or Y. This affected CNC machines with rotational axes, and OpenPnP.
-- Fixed a buffer overflow when the number of filaments reported by PrusaSlic3r exceeds the maximum number of supported extruders
-- Fixed bug in GetProportionDone that might have caused an incorrect extrusion amount for the first move after restarting a print following a power failure
-- Fixed crash that occurred on some systems when M918 was used to configure a 12864 display but no SD card was present
-- Fixed issue with G29 S1 on Duet 3 with attached SBC causing the print to fail if any if the probe points had been unreachable when the height map was probed
-- G2 and G3 commands with R parameter always drew the longer of the two possible arcs. Now they draw the shorter one if the R parameter is positive, or the longer one if it is negative.
-- G92 Znn didn't clear zDatumSetByProbing
-- G92 commands incremented seqs.move when they didn't need to
-- If M918 was run multiple times, available RAM was lost because of a memory leak
-- If M997 S4 was used but no aux port was configured, the firmware could reset after 20 seconds
-- If a G31 command defined new values in terms of existing G31 values from the object model, then incorrect values could be set due to the new values being computed and stored multiple times
-- If a TMC22xx driver received two commands to enable/disable the drive or change microstepping twice in very quick succession, the second one was sometimes lost
-- If bed compensation taper (M376) was used, bed compensation was not applied correctly if the tool had a Z offset
-- In M122 reports, queued GCodes were printed with spurious characters after each command
-- In Marlin mode, "ok" was returned per-command instead of per line of GCode
-- In RepRapFirmware mode, empty responses to commands were not suppressed. They are now suppressed except when the command came from HTTP or SBC.
-- Incorrect M307 default parameters were used for bed and chamber heaters
-- Laser and magnetic filament monitors paused the print even when disabled if no data was received or the sensor reported an error
-- Loading IAP during a firmware upgrade might fail on Duet 2 if a filament monitor or fan tacho was active
-- M118 P0 didn't append newline when the message was sent to USB and Telnet
-- M669 K5 reported that the kinematics matrix was invalid
-- M918 P0 reported an error instead of just deleting any existing display
-- Object model variable seqs.spindles was not updated when the configuredRpm of a spindle was changed
-- PanelDue was not updated while the firmware was waiting for a heating or delay command to complete
-- Some types of underrun in the movement queue were not reported
-- The Error Status word was incorrectly prefixed by 0x02 in beta1 instead of just 0x
-- The M409 response didn't end in newline and was invalid JSON if RRF ran out of output buffers. Now RRF returns {"err":-1} if it runs out of buffers, and the response is always terminated by newline to help clients recover from errors.
-- The PWM frequency for heaters was supposed to be limited to 1KHz but this check was no longer being performed
-- The handling of out-of-buffer situations when generating HTP responses has been improved. Where a JSON response was expected, RRF will generally now return {"err":-1} if there was insufficient buffer space to satisfy the request.
-- The output from M207 without parameters was truncated when there were 4 or more tools
-- When a GCode file included very short moves, sometimes the print paused for a time (sometimes a very long time) at that point
-- When doing a simple G30 command the the probe type was BLTouch, the deploy and retract macro files were each run twice
-- When the machine was executing resume.g, the 'resuming' status was not reported in the object model
-- [Duet + SBC] Fixed several issues with communication between the Duet and the SBC
-- [Duet 2 or 3 with attached SBC only] The height map parameters passed by the SBC were not range-checked
-- [Duet 3 + SBC] When file daemon.g was requested, spurious warning messages could be displayed
-- [Duet 3 + expansion/tool boards] The idle timeout was not always applied to remote drives, in particular to extruder drives
-- [Duet 3 MB6HC + expansion/tool boards] Sometimes the main board would not receive status messages from expansion and tool boards after power up unless it was reset by M999 or emergency stop
-- [Duet 3 MB6HC] A watchdog timeout didn't save any software reset data
-- [Duet 3 MB6HC] Fixed an issue that very occasionally caused a MemoryProtectionFault from the Ethernet task
-- [Duet 3 MB6HC] The second aux port using the IO_1 connector did not work
-- [Duet 3 expansion and tool boards] Thermostatic fans connected to expansion/tool boards would occasionally blip spuriously
-- [Duet 3 with attached SBC] When an array parameter (e.g. M92 E value) had more than one element but less than the maximum number, the last element was replicated to fill the array. This was inconsistent with non-SBC behaviour, which only pads the array when a single element is provided.
-- [Duet 3] DHCP requests were being made made much too often when the DHCP lease time was long e.g. 1 hour or more
-- [Duet 3] Fixed a bug that caused strange behaviour during homing in some configurations when axis motors were connected to expansion boards
-- [Duet 3] M915 with just P and/or axis parameters did not report the coolStep threshold (T parameter) correctly
-- [Duet 3] When using a LinearAnalog sensor, the readings returned were too high above the minimum reading by a factor of 4
-- [Duet 3 Mini + CAN, also EXP3HC] Fixed missing cache invalidate after receiving a CAN message
-- [Duet 3 + SBC] When attached to a SBC, M29 commands received locally are now sent to the SBC for processing
-- [Duet + SBC] A buffer overflow might occur in the SBC interface code under conditions of heavy traffic
-- [Duet + SBC] When nested macros were used, commands were sometimes executed out-of-order
-- [LPC/STM port, might affect Duets in rare situations] If hiccups occurred frequently and there was other activity in the system causing frequent high-priority interrupts, a watchdog timeout could occur
-
-Other improvements and changes:
-- Calls to debugPrintf use less stack than before
-- Efficiency improvements to TMC2208/2209/2224 drivers for both main and tool boards
-- Substantial performance improvements and much higher maximum step rates on Duet 3 MB6HC, EXP3HC and TOOL1LC boards
-- In the M122 report, unused stack for each task is now reported in dwords, not bytes
-- [Duet 3] CAN diagnostics have been improved
diff --git a/ReleaseNotes/3.3.md b/ReleaseNotes/3.3.md
deleted file mode 100644
index ec3ef4e8..00000000
--- a/ReleaseNotes/3.3.md
+++ /dev/null
@@ -1,205 +0,0 @@
-Upgrading from a stable version earlier than 3.2.2? Please see the full changelog for previous stable versions of RRF here: https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x
-
-RepRapFirmware 3.3
-==================
-
-Known issues:
-- If the slicer uses the M486 command to label objects in the GCode file, and there are more than 20 (Duet 2) or 40 (Duet 3) objects, then RRF crashes when printing the file. This bug was also present in release 3.2.x. 
-- If you home any axes when workplace coordinates are in use, then any absolute moves in the homing files have workplace coordinate offsets applied; whereas they should not. This is a new bug in release 3.3.
-- When M955 reports the configuration of an accelerometer that is connected to the main board using SPI, the orientation is always reported as 20 even if a different orientation has been selected (and is being used) by means of the M955 I parameter.
-- If a M117 command is executed when there are pending moves in the movement queue, a "string too long" error message is generated and the command is not executed. Workaround: use M400 immediately before M117.
-- When a line of received GCode includes a line number and checksum, RRF ignores a bad checksum
-- [Duet 3 + CAN-connected expansion boards] If a sequence of short movements is commanded involving only motors connected to expansion boards, then the moves might be sent too quickly to the expansion boards, eventually resulting in lost moves.
-
-Upgrade notes:
-- **All extruders must be declared explicitly using M584.** In previous firmware versions, one default extruder was assign to driver 3.
-- In previous versions, if a parameter letter should have been followed by a number but no digits were found, zero was assumed. Now RRF reports an error and abandons the command instead. 
-- Firmware files are now stored in folder /firmware of the SD card instead of /sys
-- Unless you are running with an attached SBC, you must also upload the new Duetx_SDiap32_xxx.bin file for your board. Until you do, you will not be able to upgrade/downgrade from 3.3 firmware to other versions. The new IAP files have the same names as the previous IAP files for RRF3.2 and 3.2.2 and will also work with those versions of RRF.
-- Previously the command M106 R (with no P parameter and no value after R) would restore the last saved default print cooling fan speed, and if you did supply a value after R then that value was ignored. Now it is mandatory to specify a restore point number after R.
-- Fan speeds are no longer restored automatically when resuming a print. If you change the print cooling fan speed in pause.g, restore it in resume.g using M106 R1.
-- At the start of a tool change, the speeds of individual fans are no longer saved; however the speed of the default print cooling fan is saved in restore point 2. In the unlikely event that you need to save the speeds of individual fans before a tool change, you can retrieve the speeds from the object model and save them in variables.
-- The use of M106 with both P and R parameters is now deprecated and we plan to remove this facility in RRF 3.4. If you need to save/restore individual fan speeds, retrieve the speeds from the object model and save them in variables.
-- In preparation for for general input shaping in RRF 3.4, the M593 command now takes a P parameter to specify the input shaping type. Valid values in this release are "none" and "daa" or uppercase versions of those.
-- In the unlikely event that you have multiple Z probes and they all need the same non-empty deploy/retract sequence, you will need to create separate deployprobeN.g and retractprobeN.g for each probe, where N is the probe number. This is because only probe 0 now falls back to looking for deployprobe.g and retractprobe.g.
-- M675 can now only be used with a probe, not with an endstop (which didn't make much sense anyway). The K or P parameter must be provided.
-- M675 now uses parameter K for the probe number, in keeping with G29 and G30. Parameter P is still accepted as an alternative, for backwards compatibility.
-- M675 now calls the deploy and retract files for the selected probe
-- Previously, when M675 was executed the final position was saved in restore point 2, however this behaviour was not documented. The final position is no longer saved in a restore point. Use can use the G60 command after M675 if you want to save the position.
-- M585 now requires the F parameter to be provided
-- M585 now uses parameter K for the probe number, in keeping with G29 and G30. Parameter P is still accepted as an alternative, for backwards compatibility.
-- Previously, when M585 was executed the initial position was saved in restore point 2, however this behaviour was not documented. The initial position is no longer saved in a restore point.
-- Previously, when daemon.g was not found or after it had finished running, RRF paused for 1 second before trying to open it again. That time has been increased to 10 seconds to reduce the load on the SD card. If you need a daemon to execute more often than once every 10 seconds, use a loop inside the daemon.g file.
-- Spindle management and control has been fully rewritten and now resembles better what NIST GCode standard proposes. See M950, M563, M3, M4 and M5 description in [GCode wiki](https://duet3d.dozuki.com/Wiki/Gcode) for details.
-- **G31 Cnnn (temperature coefficient) parameter has been moved to G31 Tnnn** to make C available as an axis (see new features below)
-- The object model for the height map (move.compensation.probeGrid) has changed
-- The object model for resonance compensation (move.daa) has moved
-- The height map file format has been extended. Height maps generated by earlier versions of RRF can still be loaded by this version, but height maps generated by this version of RRF cannot be loaded by earlier versions.
-- **When changing tool, tool change files are now run regardless of whether axes have been homed or not.** You can use conditional GCode to choose which commands are only executed if axes have been homed.
-- **RepRapFirmware no longer tries to work out what layer number is printing, and no longer provides an estimate of print completion time based on layer progress.** The mechanism to work out the layer number failed in many cases, for example when the slicer used variable layer heights or printed multiple objects one at a time. The removal of these 200 lines of hard-to-maintain code has made more space available for other features on the older Duets that are tight on memory space. A consequence of this change is that DWC will no longer produce a layer chart if the GCode file being printed does not include layer number comments. For slicers that do not normally generate these comments (e.g. PrusaSlicer) it is usually possible to add a layer change script to generate them.
-- [Duet 3 Mini] Immediately after upgrading to this release you may get spurious overheat warning messages for all the stepper drivers. If this happens, turn off VIN power to the Duet, wait a few seconds, and power on again.
-- [Duet 3 + expansion/tool boards] You must update the expansion and/or tool board firmware to 3.3 also, otherwise movement and some other functions will not work. If you accidentally end up with firmware 3.3 on a tool or expansion board and 3.2.x on the main board then the tool/expansion board will not achieve CAN sync with the main board; however it will still respond to some commands including M115, M122 and M997.
-- [EXP1XD board] Previously, the step pulse width requested in the M569 command was rounded up to the next multiple of 1.33us. Now it is rounded up to the next multiple of 83ns. Additionally, the step pulse interval ands the hold time from the trailing edge of the step pulse to direction change are timed from the start of the step pulse, after adjusting for the width of the step pulse. The effect of these changes is that the step pulse width, step pulse interval, and step-to-direction hold time may not be rounded up as much as before; so M569 T values that used to work only because of the rounding up that occurred may no longer work.
-
-New features:
-- When a "Bad command" error message is generated, any non-printing characters in the received command are shown in hex to make sure that they are visible
-- Fan RPMs down to 160 are now reported correctly (the previous lower limit was 320)
-- In the G38.2 command, parameter K can now be used to select the probe number
-- The CAN diagnostics in M122 reports have been greatly improved
-- When rehome.g is called because of motor stalls, for each axis for which a stall was detected, a parameter with value 1 is passed. This means that rehome.g can use tests such as "if exists(param.X)" to determine which axes need to be re-homed.
-- At the start of a print from SD card, the XY plane is selected for G2/G3 moves
-- G60 now saves the print cooling fan speed in the restore point
-- If M106 is used with a R parameter but no P parameter, the R parameter value is now the restore point number to get the speed from. Previously there was only one saved value for the default print cooling fan.
-- For filament monitor types 4 (magnetic + switch) and 6 (laser + switch), M591 with just the extruder number parameter now reports the filament present/not present status
-- M595 supports a new optional Q parameter to allow the configuration of the secondary movement queue to be changed
-- M669 when using Hangprinter kinematics now allows the XY coordinates of the D anchor to be specified
-- Hangprinter kinematics now supports line build-up compensation
-- The delay before trying to open the daemon.g file has been increased from 1 to 10 seconds, except for the first time. This reduces contention for the SD card.
-- The M122 report now includes the firmware date and time
-- The M122 report now shows the CPU utilisation per task. The reported figures will be inaccurate if more than approx. 90 minutes has elapsed since M122 was last run (or power on if M122 has not been run before).
-- New 'exists' function can be used to check whether a variable or parameter exists before using it
-- Accelerometers are supported, currently in standalone mode only (not in SBC mode). They can be connected directly to a main board via SPI, or connected to a SAMMYC21 via I2C.
-- RGBW NeoPixels LED strips are supported
-- Bit-banged NeoPixel LED strips are supported on Duet WiFi/Ethernet. On these boards RRF will wait stop movement while updating the LED strip, so M150 commands should not be issued while the machine is printing, other than at places where a short pause is acceptable such as at layer change and in the start and end scripts.
-- The maximum length of a NeoPixel strip is now 240 on Duet 3, 80 on Duet 3 Mini, and 60 on Duet 2
-- Tool offsets are now reported to 3 decimal places instead of 2 in G10 and in the object model
-- Object labelling in GCode files produced by Ideamaker are now recognised
-- Print time remaining comments in GCode files produced by Ideamaker are now recognised and processed like M73 commands
-- M25, M226 and M601 all accept a P0 parameter, which causes pause.g not to be run. M24 accepts a P0 parameter, which causes resume.g not to be run. Caution: in RRF 3.4 this is likely to be replaced by a P"filename" parameter.
-- Added M569.2 which allows any TMC22xx or TMC51xx stepper driver register to be read or written
-- A separate task is now used to finalise moves for execution
-- Data returned by TMC2209 drivers is now CRC checked
-- GCode meta commands now provide for creating local variables ('var' command) and global variables ('global' command), changing the values of variables('set' command), and parameters to macro files
-- M558 now accepts either one or two F values, e.g. F1000:300. If two values are provided, then when executing a G30 command with no P parameter an additional probe using the first speed will first be done to establish the approximate Z=0 position, followed by one or more probes (controlled by the A parameter) to establish Z=0 more precisely.
-- When using an analog Z probe, the probing speed is no longer reduced when the probe is close to triggering. Use the new M558 facility to do fast-then-slow probing instead, if necessary.
-- M568 has been repurposed as Set Tool Settings. It can be used to set tool offsets, tool temperatures and tool spindle RPM. G10 can still be used to set temperatures. M568 can also be used to switch tool heaters between off/standby/active without needing to select or deselect the tool.
-- M557 has been extended to allow defining a grid between an arbitrary axes pair, e.g. X-A and is no longer restricted to X-Y.
-- G31 has been extended to allow setting offsets for all axes (except Z)
-- M997 accepts a new parameter P"filename" to specify the filename to use for a firmware update. This can only be used when exactly one module is to be updated, i.e. it will not work with M997 S1:4
-- M669 S and T parameters are now supported on all kinematics. This allows segmentation to be used on Cartesian, CoreXY etc. and linear delta kinematics, for the purpose of allowing faster response to pause commands, M220 etc.
-- Auto calibration of rotary delta machines is supported experimentally
-- M486 now returns an error message if you try to cancel or resume an unknown object
-- Estimated print time provided by the slicer (using M73 commands if present) is now available. Estimated print completion time based on layer progress has been removed.
-- M408 and rr_status no longer report first layer duration or first layer height
-- Maximum step rates on all boards have been improved
-- Maximum length of expressions passed from DSF to RRF has been increased from 100 to 256 characters
-- When extracting file information, the support for Kiro Moto, Matter Control, Pathio, Fusion 360, IdeaMaker and SuperSlicer slicers has been improved
-- When executing G2 and G3 arc movement commands, the segments are finer than before
-- The maximum number of tracked objects has been increased, and space for the object names is now allocated dynamically
-- M17 is implemented
-- G17, G18 and G19 are now supported
-- Added M595 R parameter (thanks markmaker)
-- Increased the number of build plate objects tracked from 32 to 40 on Duet 3 and 3 Mini
-- [Duet 3 Mini] As an experiment, the MCU temperature sensor has been enabled. The manufacturer's errata document states that the sensor is not supported and should not be used; however it does appear to give useful readings, on some samples at least.
-- [Duet WiFi/Ethernet] When using extended step timings (M569 T parameter), maximum step pulse rates are improved a little
-- [Duet 3 Mini] M954 is partially implemented, allowing a Duet 3 MB6HC or Duet 3 Mini to be used as an expansion board. In this mode it can support axis motors, extruder motors (but extruders with nonzero pressure advance has not been tested), thermistor, PT100 and thermocouple temperature sensors, GpIn and GpOut pins (including servos). Heaters, fans, filament monitors, endstop switches, Z probes and other types of temperature sensor are not yet supported.
-- [Duet 3 MB6HC] The maximum number of axes supported on Duet 3 MB6HC is increased to 15. Axis letters abcdefghijkl may be used in addition to XYZUVWABCD. Because GCode is normally case insensitive, these must be prefixed with a single quote character in GCode commands. For example, M584 'A1.2 would assign axis 'a' to driver 1.2, and G1 'A10 would move the 'a' axis to the 10mm or 10 degree position (or by 10mm or 10 degrees if in relative mode).
-- [Duet 3 expansion/tool boards] Heater tuning is now implemented (M303) along with heater feedforward
-- [Duet 3 and 3 Mini with CAN-connected expansion boards] Endstops and Z probes connected to the main board can now stop motors connected to expansion boards, removing the previous limitation. However, a small amount of undetected overshoot may occur when a homing or probing move is stopped. Until this is resolved in a future release, we advise against repeated probing (e.g for mesh bed compensation) when the Z motor(s) are connected to expansion boards, or measuring axis length using G1 H3 moves when the axis motor(s) concerned are connected to expansion boards.
-- [Duet 3 + expansion/tool boards] Improved the accuracy of CAN clock synchronisation between main and expansion boards
-- [Duet 3 EXP1XD] All step pulses generated by the EXP1XD now have exactly the same step high time as set by M569. The first M569 T value (step high time) will be rounded up to the next multiple of 0.0833us subject to a minimum of 0.25us (previously it was rounded up to the next multiple of 1.33us). The remaining T values will be rounded up to the next multiple of 1.33us as before. The fourth T value (direction hold time from trailing edge of step pulse) can now be negative, down to minus the step-high time.
-- [SAMMYC21] The sample firmware for SAMMYC21 now sends a diagnostic report to the USB port if character D is received from the USB port
-- [Duet + SBC] SBC interface diagnostics have been improved
-
-Object model changes:
-- Restore points now have an additional field 'fanPwm'
-- The object model for Hangprinter kinematics has changed. Fields anchorA, anchorB, anchorC and anchorDz have been replaced by a single 4-element array called anchor.
-- If you are using `spindles[].active` or `spindles[].current` they will no longer be negative for counter-clockwise RPM but additionally carry a new field `spindle[].state` that will have one of the three values `stopped`, `forward` or `reverse` and need to be interpreted together.
-- `spindles[].tool` has been replaced by `tool[].spindle` and reverses the assignment.
-- The height map object move.compensation.probeGrid has been changed to allow for axes other than X and Y
-- The resonance compensation object move.daa has been replaced by move.shaping to support more general input shaping. The members of move.shaping have not been finalised yet.
-- Added move.queue to object model, describing the main and (if present) aux movement queues
-- Added job.pauseDuration which is the total pause time since the job started
-- Added job.timesLeft.slicer
-- Added sensors[].probes[].speeds which is a 2-element array
-- Added global variables to the object model
-- job.warmUpDuration is now flagged live
-- job.layer is now only available if the GCode file being printed includes recognised layer number comments
-- The following object model fields are now flagged as obsolete and will generate a warning when used:
-    - sensors[].probes[].temperatureCoefficient (use temperatureCoefficients[0] instead)
-    - sensors[].probes[].speed (use sensors[].probes[].speeds[1] instead)
-    - move.compensation.probeGrid.(axis0, axis1, xMin, yMin, xMax, yMax, xSpacing, ySpacing) (use axes[], mins[], maxs[], spacings[] instead)
-    - move.workspaceNumber (use move.workplaceNumber - 1 instead)
-    - job.firstLayerDuration (it will always return null)
-    - job.timesLeft.layer (it will always return null)
-
-Bug fixes:
-- If a tool heater was tuned using M303 with T parameter, and turning on the print cooling fan made no significant difference to the cooling rate, tuning would sometimes fail with a "bad curve fit" message
-- If a macro was aborted because a movement command failed, the error message was lost
-- It was not possible to use math operators with some unsigned object model fields e.g. job.filePosition and job.file.size
-- When a long-running command was initiated from PanelDue (e.g. mesh bed probing or delta auto calibration), "Bad command" and "Error parsing response" errors were sometimes reported on PanelDue
-- M595 with an out-of-range Q parameter would reset the machine due to an uncaught exception
-- M671 allowed up to 8 XY coordinates to be provided, but this should have been 4 (the maximum supported by the bed levelling algorithm)
-- M3 and M4 commands with both P and S parameters didn't work correctly
-- If pause.g, filament-change.g or filament-error.g used M291 to display a message and wait for a response, movement resumed until the response was provided
-- If a reset occurred because of an assertion failure, out-of-memory error or uncaught exception, then the task name in the software reset data in a subsequent M122 report was often corrupted depending on which task it was
-- Removed support for implicit G2/G3 commands because they is not part of the NIST GCode standard
-- Fixed M308 "string too long" message when configuring a thermocouple
-- Fixed memory protection fault or stack overflow crash when trying to pass macro parameters from DCS to RRF on Duet 3 MB6HC
-- When using polar, SCARA or Hangprinter kinematics the default segment length was not set up correctly, leading to the wrong size segments unless M669 was used with a T parameter
-- Added stack checks to recursive expression evaluation functions so that deeply nested expressions in user input abort gracefully instead of causing a reset
-- Using boards[n].shortName or boards[n].firmwareVersion in an echo command cleared any existing result string
-- Hangprinter kinematics reported itself as SCARA
-- Hangprinter kinematics needed segmentation for Z moves as well as XY moves, to maintain tension in all the cables
-- Rotary delta kinematics now uses segmented Z moves
-- M409 command now permits empty K and F parameters
-- If the pause.g file turned off the print cooling fan and deselected the tool (in either order) then the fan speed could not be restored in resume.g
-- Thermocouple sensors could not be configured because M308 didn't accept more than 20 characters in the sensor type name
-- When using a mixing extruder, if multiple E values were provided in a G0..G3 command but fewer than the number of extruders used by the current tool, the additional extrusion amounts were undefined
-- The Hangprinter kinematics code sometimes attempted to take the square root of a negative number
-- M675 command did not work reliably (old bug)
-- M675 ignored any deploy and retract macro files for the probe (old bug)
-- M675 R parameter did not take account of the inches/mm setting (old bug)
-- M675 did not report errors if the probe was already triggered at the start of the probing move, or if the probe was not triggered by the end of the probing move (old bug)
-- M585 using a probe ignored any deploy and retract macro files for the probe (old bug)
-- M585 using a probe did not report errors if the probe was already triggered at the start of the probing move, or if the probe was not triggered by the end of the probing move (old bug)
-- Object model value 'seqs.inputs' was not incremented when various fields of object model array 'inputs' were changed, so DCS and DWC didn't keep the values up to date
-- Tool names were incorrectly converted to lowercase and had spaces removed 
-- Retrieving 'tools[n].offsets[n]' from the object model failed with an error message
-- The 2-driver expansion board on a Duet Maestro or Duet 3 Mini used a separate channel to make it available as a pseudo temperature sensor, however that channel was not accessible. Those drivers are now included in the main channel.
-- The object directory state was not saved in resurrect.g because it was incorrectly written to config-override.g instead
-- G92 with an axis letter parameter also changed the accumulated extruder position reported by M114
-- DAA was often not applied where it should have been
-- When more than about 15 tools were configured, the object model fragment describing the tools was too long to send, causing DWC to disconnect
-- Job progress information was returned too infrequently when simulating
-- If a file was printed or simulated a second time, filament- and slicer-based print time estimates were not produced
-- Slicer-based time estimates were produced even when simulating a file
-- The original selected tool was not restored after simulating a file
-- Bed heater settings were not written to resurrect.g was if there was also an active chamber heater
-- When file resurrect.g was created due to a pause or power failure, settings for thermostatic fans were saved instead of settings for non-thermostatic fans
-- M500 did not persist the M307 Inn value and thus making inverted heaters non-inverted after M501
-- Pulsed filament monitors were active even when disabled by using S0 in the M591 command
-- Rarely, a height map generated by G29 S0 could not be loaded by G29 S1 due to rounding error
-- Most commands that took a pin name parameter did not accept an expression as the pin name
-- G4 with zero delay did not wait for movement to stop
-- G2/G3 commands with R parameter sometimes cause the job to abort
-- If a simulation was aborted due to an error, motion sometimes occurred
-- When waiting for a heater to reach temperature with M109 there were no more updates sent to PanelDue
-- It was not possible to delete a temperature sensor using M308 S# P"nil"
-- When a sensor was configured on a CAN expansion board and M308 was subsequently used to create a sensor with the same number on a different board, the old sensor was not deleted
-- [Duet 3 Mini] The stall detection sensitivity register was set incorrectly
-- [Duet 3 Mini] DHT sensors did not work. DHT sensors on the Duet 3 Mini now require both an output pin and an input pin. Note, support for DHT11 is likely to be removed soon.
-- [Duet + SBC] It was not possible to update PaneDue firmware using M997 S4
-- [Duet + 12864 display] The firmware would crash or behave unpredictably if in a 12864 display menu file an attempt was made to display an image at a position such that any row of the image was beyond the last row of the display
-- [Duet WiFi/Ethernet] Driver 11 connected to CONN_LCD did not work. It should now work provided that you have not configured a 12864 LCD.
-- [Duet 3 + expansion 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 + expansion boards] Under conditions of high movement density, a small number of motion commands might not be received by the expansion board
-- [Duet 3 expansion/tool boards] Under conditions of heavy load (e.g. a series of short moves at high step pulse rates), the board could stop responding to CAN commands and lose CAN sync
-- [Duet 3 + expansion 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 + expansion boards] Fixed a race condition in the CAN driver that might result in delayed messages, or in rare cases loss of CAN communication
-- [Duet 3 Mini] When a low PWM frequency (e.g. 10Hz) was used on a heater, then movement was sometimes disrupted causing sudden jerks. Heaters connected to OUT0 and OUT2 suffered from this but OUT1 did not. Even lower PWM frequencies (e.g. 5Hz) disrupted SD card access too.
-- [Duet 3 Mini] M122 often reported communication timeouts with the TMC2209 drivers
-- [Duet 3 MB6HC] The DotStar LED driver did not work because the brightness was always set to zero
-- [Duet 3 Mini] 'state.atxPower' was always reported as 'false' in the object model after an M80 or M81 command
-- [Duet 2 + DueX] If in the M652 command the laser was configured to use a fan or GPIO port on the DueX, the firmware crashed when the laser was used. It is no longer permitted to configure a laser on these ports.
-- [Duet 2 WiFi and Duet 3 Mini 5+ WiFi] Using the C (channel number) parameter in M589 did not set the channel and caused loss of communication between the Duet and the WiFi module
-- [Duet 3 expansion/tool boards] When a tool/expansion board announced itself to the main board, it corrupted the sensors report message
-- [Duet 3 + expansion/tool boards] A M116 command at the start of a tpost#.g file might not wait for a tool heater connected to an expansion or tool board to reach temperature if the tool heater was off before the tool was selected
-- [Duet 3 + expansion/tool boards] Spurious CAN transmit timeouts were reported by main boards in the M122 report
-- [Duet 3 expansion/tool boards] The free system stack was always reported as zero
-- [Duet 3 expansion/tool boards] Occasionally the red status LED would briefly flash rapidly indicating loss of CAN sync, when in fact sync had not been lost
-- [Duet 3 + expansion/tool boards] When a motor on an expansion board was commanded to move when not already enabled, and other commands were being sent to expansion boards concurrently, "Discarded message" warnings were sometimes generated
-- [Duet 3 + expansion/tool boards] An expansion or tool board would very occasionally reset without warning because of a race condition. The software reset data in the M122 report for that board reported an assertion failure.
-- [Duet 3 MB6HC + expansion/tool boards] There was excessive clock jitter on expansion/tool boards because the CAN timestamp counter in the MB6HC MCU does not always operate in accordance with the manufacturer's documentation
-- [Duet + SBC] RRF updated job.lastFileName as soon as the print started. RRF no longer reports job.lastFileName while a print is in progress.
-- [Duet + SBC] The SBC task stack might overflow when a 'set' command was received from the SBC and executed
diff --git a/ReleaseNotes/3.4.0beta6.md b/ReleaseNotes/3.4.0beta6.md
deleted file mode 100644
index 43ceea56..00000000
--- a/ReleaseNotes/3.4.0beta6.md
+++ /dev/null
@@ -1,56 +0,0 @@
-Upgrading from a 3.4 beta before 3.4b5? Please see the full changelog for previous beta versions of RRF 3.4 here: https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta-&-RC
-Upgrading from a previous stable version? Also see  the full changelog for previous stable versions of RRF here: https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x
-
-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 MB6HC and 3 Mini] 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 + expansion 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)
-- When using Polar kinematics the A and F parameters didn't work (this was a new bug in 3.4beta)
-- 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.
diff --git a/ReleaseNotes/3.4.0beta7.md b/ReleaseNotes/3.4.0beta7.md
deleted file mode 100644
index ba906fe7..00000000
--- a/ReleaseNotes/3.4.0beta7.md
+++ /dev/null
@@ -1,57 +0,0 @@
-Upgrading from a 3.4 beta before 3.4b6? Please see the full changelog for previous beta versions of RRF 3.4 here: https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta-&-RC
-Upgrading from a previous stable version? Also see  the full changelog for previous stable versions of RRF here: https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x
-
-
-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 + tool/expansion 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.
-- [Duet 3 + prototype EXP1HCL closed loop boards] 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 event 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
-- 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 printers] Under some conditions, incorrect tower movement occurred (new bug in RRF 3.4beta series)
-- [Polar printers] Fixes to polar kinematics
-- [Duet 3 expansion and tool boards] If a Linear Analog sensor was configured on an expansion or tool board, the board crashed
-- [Duet 3, 3 Mini] If M122 was run when the printer was halted, the machine reset and recorded a Hard Fault
-- [Duet 2 SBC build] 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 build] Height maps were not saved to file in 3.4.0beta6
-- [Duet 3 Mini, tool board] 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 with ODrives] Fixes to the ODriver CAN interface
-- [Duet 3 using MB6HC or Duet 3 Mini as expansion board] 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