RepRap Firmware Status responses

From RepRapWiki
Jump to: navigation, search


Because the old-style Duet status response has become somewhat clumsy, I (chrishamm) decided to introduce a new status response in RepRap Firmware. Its main goal is to achieve better readability and enhanced flexibility for different machine setups. They may be utilised either from the HTTP server (see rr_status&type request in my firmware fork) or from an attached device using the "M105 S" code.

Please note: These changes haven't been officially released yet, so if there are any comments or suggested improvements, please edit this page and make your changes.

Contents

Overview

In general, there shall be three different response types depending on the values required:

  1. Default status response
  2. Enhanced status response
  3. Print status response

Types 2) and 3) shall begin with the default response, but additional key/value pairs may be added.

Design guidelines

To avoid messing up this new status response in the future, it's mandatory to keep these design guidelines in mind:

  1. Per cent values are reported as floats on a scale between 0 and 100. Their precision may differ
  2. Feedrates and accelerations are given in mm/sec or mm/sec²
  3. Temperatures are floats with exactly one decimal place
  4. Boolean values are displayed as either 0 (false) or 1 (true)
  5. Durations and times are reported in seconds with at least one decimal place
  6. Any of the following responses must represent valid JSON data
  7. Keep JSON key names unique. That's because expansion electronics may not know which response type they're processing
  8. Also try to keep JSON fields as short as possible and don't use underscores. Use capital letters instead

Status Response Definitions

Default Status Response (type 1)

The default status response is indended to report basic 3D printer values and it shall contain only those parameters that are expected to change quickly. Its keys must be either encapsulated or have unique names to ensure the JSON data remains valid even if additional key/value pairs are added by other status response types.

Here an example for a machine with one tool, two nozzles and two extruder drives:

{
	"status": "STATE",
	"coords": {
		"axesHomed": [0, 0, 0],
		"extr": [0.0, 0.0],
		"xyz": [0.0, 0.0, 0.0]
	},
	"currentTool":1,			// -1 means none
	"output":{				// This
		"beepDuration": 3000,		// is					// These are only included
		"beepFrequency": 2000,		// missing				// in webserver responses
		"message": ""			// by
	},					// default
	"params": {
		"atxPower": 0,
		"fanPercent": [100.0, 35.0],	// NOTE: This used to be a single value (up to v1.09o-ch)
		"speedFactor": 100.00,
		"extrFactors": [100.0, 100.0]
	},
	"seq":0,				// Only included in webserver status response to indicate a new G-code response
	"sensors": {
		"probeValue": 0,
		"probeSecondary": [0,0],	// Hidden for unmodulated probes, otherwise its array size depends on the probe type (usually 1 or 2)
		"fanRPM": 0
	},
	"temps": {
		"bed": {			// Missing
			"current": 20.0,	// if no
			"active": -273.1,	// heated
			"state": 0		// bed
		},				// is present
		"chamber": {			// Missing
			"current": 19.7,	// if no
			"active": 50.0,		// chamber was
			"state": 2		// previously defined
		},				// using M141 H#
		"heads": {
			"current": [25.0, 25.0],
			"active": [0.0, 0.0],
			"standby": [0.0, 0.0],
			"state": [2, 1]		// 0: off, 1: standby, 2: active, 3: fault (same for bed)
		}
	},
	"seq": 0,				// NEW: As of 1.09m-ch, these two fields for G-Code responses
	"resp": "G-Code response for PanelDue",	// may be included in AUX status responses as well (if available)
	"time": 435.2,				// time since last reset
	"scanner": {				// OPTIONAL: only reported if a scanner is attached to the Duet. NOT FINAL YET, only RRF 1.18 or later
		"status": "D"			// may be 'D'isconnected, 'I'dle, 'S'canning or 'U'ploading to Duet
		"progress": 95			// progress in per cent. This is 0 if the state is 'I', otherwise it reflects progress of the current state
	}
}

with STATE being one of:

  • C (configuration file is being processed)
  • I (idle, no movement or code is being performed)
  • B (busy, live movement is in progress or a macro file is being run)
  • P (printing a file)
  • D (decelerating, pausing a running print)
  • S (stopped, live print has been paused)
  • R (resuming a paused print)
  • H (halted, after emergency stop)
  • F (flashing new firmware)
  • T (changing tool, new in 1.17b)

Extended Status Response (type 2)

These values are considered to be rather static and aren't expected to change very frequently. This response may be polled less frequently than the standard response, but it needs to be updated, because this response provides the most important configuration characteristics.

{
	"coldExtrudeTemp": 0.0,
	"coldRetractTemp": 0.0,
	"endstops": 0,				// NEW: As of 1.09n-ch, this field provides a bitmap of all stopped drive endstops 
	"geometry": "cartesian",
	"name": "My RepRap 1",
	"probe:" {
		"threshold": 500,
		"height": 2.6,
		"type": 1
	},
	"tools": [
		{
			"number": 1,
			"heaters": [1],
			"drives": [0]
		},
		{
			"number": 2,
			"heaters": [2],
			"drives": [1]
		}
	]
}

RepRapFirmware supports the following printer geometries:

  • cartesian
  • delta
  • coreXY
  • coreXZ
  • coreYZ

Print Status Response (type 3)

This status response only adds print-related information. It may be polled instead of type 1 when a file print is in progress.

{
	"currentLayer": 0,
	"currentLayerTime": 0.0,
	"extrRaw": [0.0, 0.0],			// How much filament would have been printed without extrusion factors applied
	"fractionPrinted": 0.0,			// one decimal place
	
	"firstLayerDuration": 0.0,
	"firstLayerHeight": 0.0,
	"printDuration": 0.0,
	"warmUpDuration": 0.0,
	
	"timesLeft": {
		"file": 0.0,
		"filament": 0.0,
		"layer": 0.0
	}
}

Extended Config Response

Because some parameters are either unlikely to change or usually not required for external devices or networking clients, we should put them in a separate response. "configFile" has to stay at the end because its content may be truncated.

{
	"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],		// NEW: Introduced in v1.09n-ch
	"firmwareElectronics": "Duet (+ Expansion)",
	"firmwareName": "RepRapFirmware",
	"firmwareVersion": "1.08c-zpl",
	"firmwareDate": "2015-03-27",
	"idleCurrentFactor": 35.0,							// NEW: Also introduced
	"idleTimeout": 30.0,								// NEW: in RRF v1.09n-ch
	"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],
	"configFile":"<-- content of config.g file -->"					// NOTE: This field has been dropped. Use rr_configfile instead
}

PID, networking and other configuration parameters might be added to a future version.

See also