Move more information over to wiki and replace file contents by links

4 files changed, 6 insertions, 880 deletions

diff --git a/AddingNewKinematics.md b/AddingNewKinematics.md
index ab77aff4..30f9bb5f 100644
--- a/AddingNewKinematics.md
+++ b/AddingNewKinematics.md
@@ -1,15 +1 @@
-How to add support for additional kinematics to RepRapFirmware
-==============================================================
-
-The supported kinematics are defined in files in folder src/Movement/Kinematics. It is organised as a class hierarchy. Each supported kinematics has its own class definition. For example, class CartesianKinematics supports standard Cartesian motion kinematics. The class declaration is in file CartesianKinematics.h and the implementation is in class CartesianKinematics.cpp.
-
-To add new kinematics:
-1. Tell me the name of your kinematics and ask me (dc42) to allocate a kinematics type number for it, via the Duet3d forum. The kinematics type number will be the K parameter in the M669 command.
-
-2. Create .h and .cpp files to declare and implement the class for your kinematics. If your machine has a conventional Z axis with one or more motors that only affect the Z coordinate, and you want to support bed levelling using multiple independent leadscrews, or the facility to assist users in determining corrections to make to manual bed levelling screws, then you should derive your kinematics class from class ZLeadscrewKinematics. Otherwise it is normally appropriate to derive it directly from class Kinematics.
-
-3. In your kinematics class, override virtual functions as needed. See the comments in file Kinematics.h for a description of those functions.
-
-4. Modify file Kinematics.cpp by adding a #include directive to include the .h file that declares your new kinematics. Also modify function Create by adding a new case to create an instance of your new kinematics class when the appropriate kinematics type number is passed.
-
-DC updated 2018-05-04.
+This file is no longer maintained.  See https://github.com/Duet3D/RepRapFirmware/wiki/Adding-New-Kinematics instead.
\ No newline at end of file
diff --git a/HTTP requests.md b/HTTP requests.md
index 3d3a787b..c663f8e0 100644
--- a/HTTP requests.md
+++ b/HTTP requests.md
@@ -1,351 +1 @@
-# List of supported HTTP requests
-
-RepRapFirmware provides an HTTP interface for dealing with client requests.
-These requests are tailored for Duet Web Control in the first place but they may be used by third-party applications, too.
-
-Every request except for `rr_connect` returns HTTP status code `401` if the client does not have a valid session.
-If no machine password is set, a user session is created whenever an arbitrary HTTP request is made.
-Besides, RepRapFirmware may run short on memory and may not be able to respond properly. In this case, HTTP status code `503` is returned.
-
-In the following requests datetime strings may be used. These datetime strings are very similar to ISO8601-encoded strings but they do not contain timezone details.
-An example for such a string is `2019-12-13T21:27:00`. Make sure to follow this format where applicable.
-
-## GET /rr_connect
-
-Attempt to create a new connection and log in using the (optional) password.
-
-Supported parameters:
-
-- `password` (optional): Machine password to log in with. If omitted, this defaults to `reprap`
-- `time` (optional): Current datetime that will be used to update RepRapFirmware's internal clock
-
-Returns
-
-```
-{
-    "err": code
-}
-```
-
-where `code` may be one of the following:
-
-- `0`: Password is valid and the client's IP address is added to the list of HTTP sessions
-- `1`: Password is invalid
-- `2`: No more user sessions available. This may occur when too many client devices are connected at the same time
-
-If the password is valid, extra fields are returned:
-
-```
-{
-    "err": 0,
-    "sessionTimeout": 8000,
-    "boardType": "duetwifi102"
-}
-```
-
-- `sessionTimeout` is the idle timeout in milliseconds before a client is removed again from the list of client sessions
-- `boardType` represents the board's type
-
-Officially supported board types are:
-
-| boardType | Board | Remarks |
-| --------- | ----- | ------- |
-| duet06 | Duet 0.6 | deprecated |
-| duet07 | Duet 0.7 | deprecated |
-| duet085 | Duet 0.8.5 | deprecated |
-| duetwifi10 | Duet WiFi v1.0 ||
-| duetwifi102 | Duet WiFi v1.02 ||
-| duetethernet10 | Duet Ethernet v1.0 ||
-| duetethernet102 | Duet Ethernet v1.02 ||
-| duet2sbc10 | Duet 2 v1.0 + SBC ||
-| duet2sbc102 | Duet 2 v1.02 + SBC ||
-| duetmaestro100 | Duet Maestro v1.0 ||
-| duet3mb6hc | Duet 3 v0.6 ||
-
-## GET /rr_disconnect
-
-Disconnect again from the RepRapFirmware controller.
-
-Returns
-
-```
-{
-    "err": code
-}
-```
-
-where `code` may be `0` if the session could be removed, else it is `1`.
-
-## GET /rr_status
-
-Retrieve a status response from RepRapFirmware in JSON format.
-
-Supported parameters:
-
-- `type`: Type of the status response
-
-The value of `type` can be one of:
-
-- 1: Standard status response
-- 2: Advanced status response. This also contains fields from the standard status response
-- 3: Print status response. This contains fields from the standard status response as well as information about the current (print) job
-
-See [JSON responses](JSON%20Responses.md) for further information.
-
-## Get /rr_config
-
-Retrieve the configuration response. This request provides a JSON object with values that are expected to change rarely. 
-
-See [JSON responses](JSON%20Responses.md) for further information.
-
-## GET /rr__gcode
-
-Execute arbitrary G/M/T-code(s).
-
-Supported parameters:
-
-- `gcode`: G/M/T-code to execute. This parameter must be present although it can be empty
-
-Returns
-
-```
-{
-    "buff": bufferSpace
-}
-```
-
-where `bufferSpace` indicates how much buffer space for new G/M/T-codes is still available.
-
-If a file is supposed to be streamed over the HTTP interface, call this repeatedly and transfer only as many bytes as allowed.
-
-## GET /rr_reply
-
-Retrieve the last G-code reply. The G-code reply is buffered per connected HTTP client and it is discarded when every HTTP client has fetched it or
-when the firmware is short on memory and the client has not requested it within reasonable time (1 second).
-
-The G-code reply is returned as `text/plain`.
-
-## GET /rr_upload
-
-Get the last file upload result.
-
-Returns
-
-```
-{
-    "err": code
-}
-```
-
-where `code` can be either `0` if the last upload successfully finished or `1` if an error occurred.
-
-## POST /rr_upload
-
-Upload a file.
-
-Supported URL parameters:
-
-- `name`: Path to the file to upload
-- `time` (optional): ISO8601-like represenation of the time the file was last modified
-- `crc32` (optional): CRC32 checksum of the file content as hex string *without* leading `0x`. Usage of this parameter is encouraged
-
-The raw HTTP body contains the file content. Binary file uploads are supported as well.
-Make sure to set `Content-Length` to the length of the HTTP body if your HTTP client does not already do that.
-
-Returns
-
-```
-{
-    "err": code
-}
-```
-
-where `code` can be either `0` if the last upload successfully finished or `1` if an error occurred (e.g. CRC mismatch).
-
-## GET /rr_download
-
-Download a file.
-
-Supported parameters:
-
-- `name`: Filename to download
-
-If the file could not be found, HTTP status code 404 is returned, else the file content is sent to the client.
-
-## GET /rr_delete
-
-Delete a file or directory.
-
-Supported parameters:
-
-- `name`: Filename to delete
-
-Returns
-
-```
-{
-    "err": {code}
-}
-```
-
-where code is either `0` on success or `1` on error.
-
-## GET /rr_filelist
-
-Retrieve a (partial) file list.
-
-Supported parameters:
-
-- `dir`: Directory to query
-- `first` (optional): First item index to return. Defaults to `0`
-
-Returns
-```
-{
-    "dir": dir,
-    "first": first,
-    "files": [
-        {
-            "type": itemType,
-            "name": itemName,
-            "size": itemSize,
-            "date": itemDate
-        },
-        ...
-    ],
-    "next": next,
-    "err": code
-}
-```
-
-where `dir` and `first` equal the query parameters. `err` can be one of:
-
-- `0`: List query successful
-- `1`: Drive is not mounted
-- `2`: Directory does not exist
-
-The `next` field may be omitted if the query was not successful and it is `0` if the query has finished. If there are more items to query, this value can be used for the `first` parameter of a successive `rr_filelist` request.
-
-Retrieved files are returned as part of the `files` array. Note that `date` may not be present if it is invalid. Every item has the following properties:
-
-- `itemType`: Type of the file item. This is `d` for directories and `f` for files
-- `itemName`: Name of the file or directory
-- `itemSize`: Size of the file. This is always `0` for directories
-- `itemDate`: Datetime of the last file modification
-
-## GET /rr_files
-
-Retrieve a list of files without any attributes.
-
-Supported parameters:
-
-- `dir`: Directory to query
-- `first` (optional): First item index to return. Defaults to `0`
-- `flagDirs` (optional): Set this to `1` to prefix directory items with `*`. Defaults to `0`
-
-Returns
-
-```
-{
-    "dir": dir,
-    "first": first,
-    "files": [
-        "file1",
-        "file2",
-        ...
-    ],
-    "next": next,
-    "err": err
-}
-```
-
-where `dir` and `first` equal the query parameters. `err` can be one of:
-
-- `0`: List query successful
-- `1`: Drive is not mounted
-- `2`: Directory does not exist
-
-The `next` field may be omitted if the query was not successful and it is `0` if the query has finished. If there are more items to query, this value can be used for the `first` parameter of a successive `rr_files` request.
-
-## GET /rr_move
-
-Move a file or directory.
-
-Supported parameters:
-
-- `old`: Current path to the file or directory
-- `new`: New path of the file or directory
-- `deleteexisting` (optional): Set this to `yes` to delete the new file if it already exists. Defaults to `no`
-
-Returns
-
-```
-{
-    "err": code
-}
-```
-
-where code is either `0` on success or `1` on error.
-
-## GET /rr_mkdir
-
-Create a new directory.
-
-Supported parameters:
-
-- `dir`: Path to the new directory
-
-Returns
-
-```
-{
-    "err": code
-|
-```
-
-where code is either `0` on success or `1` on error.
-
-## GET /rr_fileinfo
-
-Parse a G-code job file and return retrieved information. If no file is specified, information about the file being printed is returned.
-
-Supported parameters:
-
-- `name` (optional): Path to the file to parse
-
-Returns
-
-```
-{
-    "err": code,
-    "size": size,
-    "lastModified": lastModified,
-    "height": height,
-    "firstLayerHeight": firstLayerHeight,
-    "layerHeight": layerHeight,
-    "printTime": printTime,
-    "simulatedTime": simulatedTime,
-    "filament": filament,
-    "printDuration": printDuration,
-    "fileName": fileName,
-    "generatedBy": generatedBy
-}
-```
-
-where `code` is either `0` on success or `1` on error. If the file could not be parsed, all other fields are omitted.
-
-Other fields are:
-
-| Field | Unit | Description | Default value if invalid | Present if `name` is omitted |
-| ----- | ---- | ----------- | ------------------------ | --------------------------- |
-| size | bytes | Size of the file in bytes | not applicable | yes |
-| lastModified | datetime | Datetime of the last file modification | omitted | maybe |
-| height | mm | Final print height of the object | 0.00 | yes |
-| firstLayerHeight | mm | Height of the first layer | 0.00 | yes |
-| layerHeight | mm | Layer height | 0.00 | yes |
-| printTime | seconds | Estimated print time | omitted | maybe |
-| simulatedTime | seconds | Estimated print time according to the last simulation | omitted | maybe |
-| filament | array of mm | Total filament consumption per extruder | empty array | yes |
-| printDuration | seconds | Total print time so far | not applicable | no |
-| fileName | file path | Absolute path to the file being printed | not applicable | no |
-| generatedBy | text | Slicer or toolchain which generated this file | empty string | yes |
+This file is no longer maintained.  See https://github.com/Duet3D/RepRapFirmware/wiki/HTTP-requests instead.
\ No newline at end of file
diff --git a/JSON responses.md b/JSON responses.md
index 28eb9caa..bc02c4e4 100644
--- a/JSON responses.md
+++ b/JSON responses.md
@@ -1,463 +1 @@
-# List of RepRapFirmware JSON Responses
-
-This document describes the four big JSON responses which are used to report status and configuration details.
-For a list of HTTP-related JSON responses, see [HTTP requests](HTTP%20requests.md).
-
-In these responses the following conditions apply:
-
-- Booleans represented as 0 (false) or 1 (true)
-- Indices pointing to another resource *might* not be valid. This is due to possible limitations of the CAN expansion board management
-- ADC readings are reported on a scale of 0 to 1000
-- Lengths are reported in mm
-- Speeds are reported in mm/s
-- Times are reported in seconds
-- Temperatures are reported in Celsius
-
-## Standard Status Response (Type 1)
-
-This status response contains various fields that are expected to change frequently. These values are also included in the type 2 and 3 status responses.
-
-```
-{
-	"status": "O",
-	"coords": {
-		"axesHomed": [0, 0, 0],
-		"wpl": 1,
-		"xyz": [0.000, 0.000, 0.000],
-		"machine": [0.000, 0.000, 0.000],
-		"extr": []
-	},
-	"speeds": {
-		"requested": 0.0,
-		"top": 0.0
-	},
-	"currentTool": -1,
-	"output": {
-		"beepDuration": 1234,
-		"beepFrequency": 4567,
-		"message": "Test message",
-		"msgBox": {
-			"msg": "my message",
-			"title": "optional title",
-			"mode": 0,
-			"seq": 5,
-			"timeout": 10.0,
-			"controls": 0
-		}
-	},
-	"params": {
-		"atxPower": -1,
-		"fanPercent": [-100],
-		"speedFactor": 100.0,
-		"extrFactors": [],
-		"babystep": 0.000,
-		"seq": 1
-	},
-	"sensors": {
-		"probeValue": 1000,
-		"probeSecondary": 1000,
-		"fanRPM": [-1]
-	},
-	"temps": {
-		"bed": {
-			"current": -273.1,
-			"active": -273.1,
-			"standby": -273.1,
-			"state": 0,
-			"heater": 0
-		},
-		"current": [-273.1],
-		"state": [0],
-		"tools": {
-			"active": [],
-			"standby": []
-		},
-		"extra": []
-	},
-	"time": 596.0,
-	"scanner": {
-		"status": "D",
-		"progress": 0.0
-	},
-	"spindles": [],
-	"laser": 0.0
-}
-```
-
-### Machine Status
-
-The `status` field provides a single character for the machine status. It may have one of the following values:
-
-| Status character | Status |
-| ---------------- | ------ |
-| C | Reading configuration file |
-| F | Flashing new firmware |
-| H | Halted (after emergency stop) |
-| O | Off (powered down, low input voltage) |
-| D | Pausing print (decelerating) |
-| R | Resuming print (after pause) |
-| S | Print paused (stopped) |
-| M | Simulating a (print) file |
-| P | Printing |
-| T | Changing tool |
-| B | Busy (executing macro, moving) |
-
-Values higher in the table also have a higher priority. So, for example, tool changes are not reported while a print is in progress.
-
-### Coordinates
-
-- `coords/wpl` (optional): Selected workplace (see G10 and G54 to G59.3). May not be present if the board does not support workplaces
-- `cords/xyz`: User coordinates of the axes (i.e. with tool offsets applied)
-- `coords/machine`: Mchine coordinate of the axes (i.e. without tool offsets applied)
-- `coords/extr` Total amount of filament extruded per extruder drive (with extrusion factors applied). See also `extrRaw` in response type 3
-
-### Output
-
-RepRapFirmware may request output via the client application. Only if this is the case, the `output` field is present.
-
-#### Beeps
-
-If no PanelDue is attached, beeps (see M300) are reported via the `beepDuration` and `beepFrequency` fields.
-These fields are not present if M300 was not used.
-
-#### Output message
-
-A user may want to output a generic message via M117. If this is the case, the message string is reported via the `message` field.
-
-#### Message boxes
-
-RepRapFirmware allows a user to use message boxes if required. These message boxes may be configured via M291/M292.
-The corresponding values can be found in the optional `msgBox` field. See the documentation of M291 for further details.
-
-- `msgBox/controls` is a bitmap of configured axis controls (X = 1, Y = 2, Z = 4 etc.)
-- `msgBox/seq` is incremented whenever M291 is used
-- `msgBox/timeout` is the time left for displaying this message box or 0.0 if it does not time out
-
-### Temperatures
-
-Slow heaters like `temps/bed`, `temps/chamber`, and `temps/cabinet` (second chamber) have the following properties:
-
-- `current`: Current heater temperature
-- `active`: Target temperature when turned on (in active state)
-- `standby`: Target temperature when in standby mode
-- `state`: State of the heater. See below
-- `heater`: Index of the assigned heater
-
-The fields `temps/bed`, `temps/chamber`, and `temps/cabinet` may not be present if no bed and/or chamber is configured.
-
-- `temps/current`: Array of heater temperatures
-- `temps/state`: Array of heater states
-- `temps/tools/active`: Array holding arrays of configured active heater temperatures. Tools may have multiple heaters assigned
-- `temps/tools/standby`: Array holding arrays of configured standby heater temperatures
-
-#### Heater states
-
-| Heater state | Meaning | Description |
-| ------------ | ------- | ----------- |
-| 0 | off | Heater is turned off |
-| 1 | standby | Heater is in standby mode |
-| 2 | active | Heater is active |
-| 3 | fault | Heater fault occurred |
-| 4 | tuning | Heater is being tuned |
-| 5 | offline | Remote heater from an expansion board is not available |
-
-#### Extra heaters
-
-Extra heaters represent custom sensor and can be found in `temps/tools/extra`. Every extra heater is reported in the following format:
-
-```
-{
-	"name": "MCU",
-	"temp": 34.7
-}
-```
-
-### Scanner
-
-RepRapFirmware may support an external interface for 3D scanners. This field is not be present if scanner support is not enabled in the firmware,
-hence this field may not be present either. There are two fields for this interface in the status response:
-
-- `status`: Status of the external 3D scanner. See below
-- `progress`: Progress of the current operation (0.0 to 100.0)
-
-Possible scanner states:
-
-| Status character | State |
-| ---------------- | ----- |
-| D | Disconnected |
-| I | Idle |
-| S | Scanning |
-| P | Post processing |
-| C | Calibrating |
-| U | Uploading |
-
-### Spindles
-
-The `spindles` field may be only present if the machine is in `CNC` mode or if the advanced status respone (type 2) is queried.
-
-It provides a list of configured spindles in the format
-
-```
-{
-	"current": 0.0,
-	"active": 0.0,
-	"tool": 0
-}
-```
-
-where `current` is the current RPM, `active` the target RPM, and `tool` the number of the assigned tool.
-
-### Other fields
-
-- `speeds/requested`: Requested feedrate of the current move
-- `speeds/top`: Top feedrate of the current move
-- `currentTool`: Selected tool number (not index) or -1 if none is selected
-- `params/atxPower`: ATX power state. This may be -1 if ATX power is not configured
-- `params/fanPercent`: Fan percent (0.0 to 100.0). If the fan is disabled, this may be negative (-1)
-- `params/speedFactor`: Speed factor override. 100% equals 100.0 and this is always greater than 0.0
-- `params/extrFactors`: Extrusion factor override values. Values of 100% equals 100.0 and they are always greater than 0.0
-- `params/babystep`: Z babystepping amount
-- `sensors/probeValue`: ADC reading of the Z probe
-- `sensors/probeSecondary` (optional): Seconday probe ADC reading if the probe is modulated. This field is not present if the probe is unmodulated
-- `sensors/fanRPM`: Array of fan RPMs, values may be negative if not configured
-- `time`: Time in seconds since the machine started. May be used to detect firmware resets
-- `laser` (optional): PWM value of the attached laser. This field is only present if the machine is in `Laser` mode
-
-## Advanced Status Response (Type 2)
-
-This status response type provides fields that may change but not as frequently as those in the standard status response.
-
-```
-{
-	"params": {
-		"fanNames": [""],
-	},
-	"temps": {
-		"names": [""}
-	},
-	...
-	"coldExtrudeTemp": 160.0,
-	"coldRetractTemp": 90.0,
-	"compensation": "None",
-	"controllableFans": 0,
-	"tempLimit": 290.0,
-	"endstops": 0,
-	"firmwareName": "RepRapFirmware for Duet 3 v0.6",
-	"firmwareVersion": "3.0beta12+1",
-	"geometry": "cartesian",
-	"axes": 3,
-	"totalAxes": 3,
-	"axisNames": "XYZ",
-	"volumes": 1,
-	"mountedVolumes": 0,
-	"mode": "FFF",
-	"name": "duet3",
-	"probe": {
-		"threshold": 500,
-		"height": 0.70,
-		"type": 0
-	},
-	"tools": [],
-	"mcutemp": {
-		"min": 24.0,
-		"cur": 37.4,
-		"max": 37.6
-	},
-	"vin": {
-		"min": 0.2,
-		"cur": 0.3,
-		"max": 0.3
-	},
-	"v12": {
-		"min": 0.2,
-		"cur": 0.2,
-		"max": 0.2
-	}
-}
-```
-
-### Geometry
-
-The current geometry is reported as part of the `geometry` field. The following geometries are supported:
-
-| Value | Geometry |
-| ----- | -------- |
-| cartesian | Cartesian |
-| coreXY | CoreXY |
-| coreXYU | CoreXYU |
-| coreXYUV | CoreXYUV |
-| coreXZ | CoreXZ |
-| markForged | markForged |
-| Hangprinter | Hangprinter |
-| delta | Linear delta |
-| Polar | Polar |
-| Rotary delta | Rotary delta |
-| Scara | Scara |
-
-If the geometry is unknown, `unknown` is reported.
-
-### Machine mode
-
-It is possible to choose between `FFF`, `CNC`, and `Laser` mode. As a consequence, the following values are reported as part of the `mode` field:
-
-| Value | Mode |
-| ----- | ---- |
-| FFF | 3D printing mode |
-| CNC | CNC mode |
-| Laser | Laser cutting/engraving mode |
-
-
-### Probe
-
-The `probe` field may not be present if no Z probe is configured. If it is, it provides the following fields:
-
-- `probe/threshold`: Threshold value for the Z probe to be triggered
-- `probe/height`: Z height of the Z probe when triggered
-- `probe/type`: Probe type. See below
-
-Possible probe types are:
-
-| Probe type | Name |
-| ---------- | ---- |
-| 0 | No probe |
-| 1 | Simple analog probe |
-| 2 | Dumb modulated probe |
-| 3 | Alternate analog probe |
-| 4 | E0 switch **deprecated** |
-| 5 | Digital probe |
-| 6 | E1 switch **deprecated** |
-| 7 | Z switch **deprecated** |
-| 8 | Unfiltered digital probe |
-| 9 | BLTouch |
-| 10 | Z motor stall detection |
-
-### Tool mapping
-
-In order to figure out the mapping between heaters and tools, the tool mapping is reported as part of the advanced status response.
-The tool mapping is reported as an array of items like
-
-```
-{
-	"number": 0,
-	"name": "",
-	"heaters": [],
-	"drives": [],
-	"axisMap": [[0],[1]],
-	"fans": 1,
-	"filament": "PLA",
-	"offsets": [0.00, 0.00, 0.00]
-}
-```
-
-where
-
-- `number`: Tool number (T*n*)
-- `name`: Optional tool name or `""` if none is configured
-- `heaters`: List of assigned heater indices
-- `drives`: List of assigned drives
-- `axisMap`: XY axis mapping. Mapped X axes are reported in the first item and mapped Y axes in the second one
-- `fans`: Bitmap of the mapped tool fans (controllable by `M106` without `P` parameter)
-- `filament` (optional): Name of the loaded filament
-- `offsets`: Tool offsets. The size of this array equals the number of visible axes
-
-### Other fields
-
-- `params/fanNames`: Array of custom fan names. Every fan name defaults to `""` if no custom name has been configured
-- `temps/names`: Custom names of the heaters. This is `""` for every heater that does not have a custom name
-- `coldExtrudeTemp`: Minimum temperature for extrusions
-- `coldRetractTemp`: Minimum temperature for retractions
-- `compensation`: Current type of bed compensation. May be either `Mesh`, `n Point` (where n is the number of probe points), or `None`
-- `controllableFans`: Bitmap of fans that are user-controllable. This excludes thermostatic fans
-- `tempLimit`: Maximum allowed heater temperature of the heater protection items. This is used for scaling the temperature chart on the web interface
-- `endstops`: Bitmap of currently triggered axis endstops
-- `firmwareName`: Name of the firmware **deprecated - see config response**
-- `firmwareVersion`: Version of the firmware **deprecated - see config response**
-- `axes`: Number of visible axes
-- `totalAxes`: Number of total axes
-- `axisNames`: Letters of the visible axes
-- `volumes`: Total number of supported volumes
-- `mountedVolumes`: Bitmap of mounted volumes (1 = drive 0, 2 = drive 2, ...)
-- `name`: Hostname of the machine
-- `mcutemp` (optional): Minimum, current, and maximum MCU temperatures
-- `vin` (optional): Minimum, current, and maximum input voltage
-- `v12` (optional): Minimum, current, and maximum voltage on the 12V rail
-
-## Print Status Response (Type 3)
-
-This status response type provides extra details about the file being processed. The format is
-
-```
-{
-	...
-	"currentLayer": 0,
-	"currentLayerTime": 0.0,
-	"extrRaw": [],
-	"fractionPrinted": 0.0,
-	"filePosition": 0,
-	"firstLayerDuration": 0.0,
-	"firstLayerHeight": 0.00,
-	"printDuration": 0.0,
-	"warmUpDuration": 0.0,
-	"timesLeft": {
-		"file": 0.0,
-		"filament": 0.0,
-		"layer": 0.0
-	}
-}
-```
-
-where the fields are:
-
-- `currentLayer`: Number of the current layer being printed
-- `currentLayerTime`: Time of the current layer
-- `extrRaw`: Total amount of extruded filament without extrusion multipliers applied. This is useful to estimate the print progress
-- `fractionPrinted`: Fraction of the file printed on a scale of 0.0 to 100.0. This equals `filePosition / fileSize`
-- `filePosition`: Byte position of the file being printed
-- `firstLayerDuration`: Duration of the first layer or 0.0 if unknown
-- `firstLayerHeight`: Height of the first layer
-- `printDuration`: Total print duration (excluding pause times) 
-- `warmUpDuration`: Time needed to warm up the heaters
-- `timesLeft/file`: Estimation for the time left based on the file consumption
-- `timesLeft/filament`: Estimation for the time left based on the filament consumption
-- `timesLeft/layer`: Estimation for the time left based on the layer times
-
-## Configuration response
-
-In addition to the responses above, the config response provides values that are not expected to change unless the machine is reconfigured.
-Note that a user may choose to reconfigure the machine at any time. The config response comes in the following format:
-
-```
-{
-	"axisMins": [0.0, 0.0, 0.0],
-	"axisMaxes": [220.0, 200.0, 180.0],
-	"accelerations": [1000.0, 1000.0, 1000.0, 1000.0, 1000.0, 1000.0, 1000.0, 1000.0],
-	"currents": [800.0, 1000.0, 800.0, 1000.0, 800.0, 800.0, 8000, 800.0],
-	"firmwareElectronics": "Duet 3 MB6HC",
-	"firmwareName": "RepRapFirmware",
-	"boardName": "MB6HC",
-	"firmwareVersion": "3.0beta12+1",
-	"dwsVersion": "1.24",
-	"firmwareDate": "2019-11-05b1",
-	"idleCurrentFactor": 35.0,
-	"idleTimeout": 30.0,
-	"minFeedrates": [10.0, 10.0, 0.5, 0.33, 0.33, 0.33, 0.33, 0.33],
-	"maxFeedrates": [250.0, 250.0, 3.0, 60.0, 60.0, 60.0, 60.0, 60.0]
-}
-```
-
-The following fields are reported:
-
-- `axisMins`: Minima of the visible axes
-- `axisMaxes`: Maxima of the visible axes
-- `accelerations`: Accelerations of the drives
-- `currents`: Configured motor currents
-- `firmwareElectronics`: Name of the firmware electronics
-- `firmwareName`: Name of the firmware (usually RepRapFirmware)
-- `boardName` (optional): Short name of the board, only applicable for Duet 3. May be `MB6HC` for Duet v0.6 or `MBP05` for the Duet v0.5 prototype
-- `firmwareVersion`: Version string of the firmware
-- `dwsVersion` (optional): Version of the DuetWiFiSocketServer (only Duet WiFi)
-- `firmwareDate`: Indicates when the firmware was built
-- `idleCurrentFactor`: Motor currents are reduced by this factor when the motors are idle
-- `idleTimeout`: Motor current reduction is performed after this time in seconds
-- `minFeedrates`: Minimum feedrates of the drives
-- `maxFeedrates`: Maximum feedrates of the drives
+This file is no longer maintained.  See https://github.com/Duet3D/RepRapFirmware/wiki/JSON-responses instead.
\ No newline at end of file
diff --git a/README.md b/README.md
index 182a8296..6385bd9c 100644
--- a/README.md
+++ b/README.md
@@ -1,55 +1,7 @@
 This is firmware for controlling 3D printers and related devices using electronics based on ATSAM main processors. The current processors supported are the ATSAM4E, ATSAM4S and SAME70. The legacy SAM3X processor is also supported. There is a fork of this firmware that supports LPC1768/1769 processors. The SAME5x processor is supported in the related project Duet3Expansion.
 
-Documentation
-=============
-For documentation on supported gcodes and configuration, see https://duet3d.com/wiki. There is a tool for generating the config.g file and homing files at https://configurator.reprapfirmware.org/.
+# Documentation
+All documentation has been moved to the [RepRapFirmware GitHub Wiki](https://github.com/Duet3D/RepRapFirmware/wiki).
 
-Support, issues and suggestions
-===============================
-If you wish to obtain support, report suspected firmware issues or make suggestions for improvements, please use the forum at https://forum.duet3d.com/ so that other users of RepRapFirmware can help you or comment on your suggestions. **I am not accepting any new Issues via github** due to repeated inappropriate use of this facility.
-
-Pull requests
-=============
-If you wish to submit a pull request that changes the existing behaviour of RepRapFirmware, please discuss the change with me and other users first via the forum at https://forum.duet3d.com/. RepRapFirmware is used in a wide variery of different machines and a change that may suit you may cause difficulties for other users. **I will reject any PRs that have not been discussed with me unless they are trivial bug fixes.**
-
-Overview and history
-====================
-RepRapFirmware was developed originally by Adrian Bowyer and his collaborators at RepRapPro Ltd. It has been in use since late 2013, first in the open-source Ormerod, Mendel and Huxley 3D printer kits supplied by RepRapPro, and subsequently in a wide variery of 3D printers. Several current kit suppliers and many manufacturers of commercial 3D printers use RepRapFirmware.
-
-Unlike most other 3D printer firmwares, RepRapFirmware is not intended to be run on outdated 8-bit processors with limited CPU power and RAM. So it makes good use of the power of modern inexpensive ARM processors to implement advanced features.
-
-RepRapFirmware has pioneered a number of advances in 3D printing including:
-
-* Support for mixing extruders (July 2014)
-* Precise timing of step pulses, even during acceleration (January 2015)
-* Accurate extruder pressure advance, including retraction before the end of a move when needed (January 2015)
-* Segmentation-free delta motion (January 2015)
-* Simulation mode, for establishing an accurate print time before committing to a print (January 2015)
-* Least-squares auto calibration of delta printers (April 2015)
-* Support for SPI-configured stepper drivers (August 2016)
-* Resume-after-power fail as a standard feature of the firmware (October 2017)
-* Compensation for the variation in extruder steps/mm with speed that is a feature of common types of extruder (January 2018)
-* Compensation of heater power for changes in power supply voltage
-* Dynamic acceleration control to control ringing
-
-Supported hardware
-==================
-Version 2 of this fork of RepRapFirmware supports electronics based on SAM4E, SAM4S and SAME70 processors; in particular the Duet WiFi, Duet Ethernet, Duet Maestro, the forthcoming Duet 3 range, and some specialist OEM boards. There is another fork that supports electronics that use the LPC1768/1769 processors. There is also an untested (by me) build for Arduino Due/RADDS
-
-Version 1 of this fork also supports hardware built around the SAM3X8E processor, such as Duet 06, Duet 085, Arduino Due/RADDS and Alligator. I no longer develop version 1 but if someone else wants to continue development of version 1 or add support for these processors in version 2, I will consider accepting related pull requests. Please note, version 2 uses FreeRTOS, and the additional memory requirement makes it difficult to fit both RTOS and LWIP network support into the 96Kb RAM limit of the SAM3X8E. One way to resolve this might be to use the TCP/IP stack that is available with FreeRTOS.
-
-General design principles
-=========================
-* "One binary to rule them all". For a given electronics board, all features of interest to most 3D printer owners are supported by a single binary. Users do not need to recompile the firmware unless they have unusual requirements.
-* "G-code everywhere". All firmware configuration is done using gcodes in the config.g file. Most types of changes can be done on the fly so that you can experiment with different configurations without even having to restart the printer.
-* Use high-integrity coding standards to help ensure that the firmware is reliable. In particular, don't use dynamic memory allocation during normal operation, use it only during the initialisation and configuration phases. The MISRA-C++ 2008 coding standard serves as a guide as to what is acceptable practice, but compliance to it is not rigidly enforced in order to allow features from later versions of the C++ language to be used.
-* Use an appropriate degree of modularity. Too little modularity makes the code hard to understand and maintain. Too much makes it hard to introduce new features when the existing module boundaries turn out to be inappropriate.
-* Use object-based and object-oriented design principles where it is appropriate. In particular, class data should normally be private. Use 'friend' sparingly or not at all.
-
-Compiling
-=========
-For compiling from source, see separate file BuildInstructions.md.
-
-Licence
-=======
+# Licence
 The source files in this project (RepRapFirmware) are licensed under GPLv3, see http://www.gnu.org/licenses/gpl-3.0.en.html. The associated CoreNG project, which provides a partial hardware abstraction layer, includes files derived from the Advanced Software Framework (formerly Atmel Software Framework) from Microchip. Those files have a more restrictive license, in particular they may only be used for code that targets Atmel/Microchip processors.