Firmware Capabilities Protocol

From RepRap
Jump to: navigation, search


While it is nice if a firmware supports some special features, it would be even better if hosts would detect that these are available so they start using them. Especially with the wild growth of firmware forks and versions, no host can know which variant can handle what. So at least for Repetier-Firmware we introduce with version 1.0 a new simple protocol to tell hosts what features are available, so they can activate them.

Protocol definition

To make it easy to detect, a standard M115 report gets now extended by one or more lines, each line telling what capability. These lines have the following format:

Cap:<NameOfCapability>:<0 or 1>

Notice: no spaces allowed, Name is upper case with underline to separate words. Lines MUST start with "Cap:" so it can be parsed very quickly by hosts.

The last value indicates if that capability is supported or not. The simple absence of a message is not enough since it would be possible, that the firmware simply does not report capabilities at all and host has to make assumptions like showing EEPROM editor even with the risk that it is not available. Whereas a 0 value shows that a function is known, but the functionality is not implemented/active.

Knowing different developers will add other capabilities is no real problem as long as all names differ, so hosts can distinguish them by name. Hosts not understanding a name simply ignore them.

Currently-defined capabilities


The firmware supports high-resolution arc and circle moves with G2 and G3.


The firmware supports auto-leveling with G29.


The firmware will auto-report the SD Card status, using M27 S to enable and set the interval.


The firmware can automatically report temperatures. This feature must be enabled by M155 S[interval] so older hosts won't get redundant reports from M105 and this feature.


The firmware supports setting the progress percentage with M73 P, required to show progress for host-based printing on the machine's display.


The firmware supports setting the case light brightness with M355 S and values 2-255.


The firmware has support for a Chamber thermal sensor.


The firmware has support for a Cooler thermal sensor, for a laser or other device that needs active cooling.


The firmware sends signals to allow hosts to warn about an open door. The messages are:


The door state message may optionally be prefixed with "echo:".


The firmware supports immediate execution of commands M108, M112, and M410. With this capability M108 can be used to break out of M0/M1, M109, and M190.


The firmware is compiled with EEPROM support.


Promotes availability of M415 to help hosts to recover from an interrupted connection or power loss. See the M415 description on the G-codes page more details about the implementation.


The firmware supports M420 V to report the stored leveling (mesh or matrix) data.


The firmware supports long filenames via the M33 command (used to asynchronously update the user-visible portion of a host-side file browser).


The firmware supports the MeatPack stream compression protocol by Scott Mudge as provided by the MeatPack OctoPrint plugin.


The firmware supports motion modes for G0, G1, G2, G3, G5, and G38, and adds the G80 command to cancel the current motion mode. With motion modes the firmware only needs the parameters for subsequent moves following one of these common motion commands.


Currently all commands are parsed in order with the exception of some emergency commands. These are executed as fast as they get detected. The problem is that they stay in queue until they get handled in correct order to provide the "ok" for host in right order to not confuse host.

Now there are cases where you need to send multiple "emergency" commands like M876 to navigate through e.g. filament change. When you need to purge several times the buffer is full and firmware does not react any more on host navigation.

There are also commands where it would be nice if they work out of order as well because we do not want to wait like babystepping or which are just informational and do not need to be executed in order like M105. Imagine being able to send M115 during slow homing and get updates.

So this is where this extension kicks in. It is designed to be fully backwards compatible to existing hosts. The idea is to have a list of codes that can be executed out of order. These commands get removed from input queue once executed and hence free the input buffer.

Sequence is as follows:

1. Report in M115 the capability for out of order execution:


2. Wait for host to confirm it understands the extension and send supported codes:

M576 S1
out_of_order:M108 M112 M290 M876

Mark feature enabled on the source serial port. When multiple ports exist not all ports may support it. The host now has a list of all codes that are handled out of order. That way the list can be extended any time without requiring host changes.

3. When an out of order command is sent to a port that supports it, it will be executed and confirmed. For example:

ooo M290

Out of order commands should be sent with no line number. That would cause problems for the sequential line numbering of regular commands. With the "ooo" instead of "ok" host knows the emergency buffer is ready and it is safe to send the next out of order command.

Race Condition: When opening a connection to the board doesn't reset the connection the firmware might have out-of-order enabled while the connecting host does not, and expects an "ok" instead of "ooo" response. To help solve the issue a call of M115 should disable out-of-order automatically until the host reenables it on next seeing the OUT_OF_ORDER capability. As long as the host sends M115 before any out-of-order commands this will solve the race condition.


The firmware allows parentheses comments within G-code lines.


The firmware allows quoted strings to be used as G-code word parameters and as "the string argument."


The firmware supports the Print Job Timer commands M75 Start, M76 Pause, and M77 Stop.


The firmware supports the progress protocol:

  • M530 S<printing> L<layer> - Enables explicit printing mode (S1) or disables it (S0). L can set layer count.
  • M531 filename - Set the filename being printed.
  • M532 X<percent> L<curLayer> - Update current print state progress (X=0..100) and layer L.

This allows a host to enable a special information mode on LCD display, so users see progress in percent, model being printed, layer being printed, and total layer count. (Hosts can also use M117 to show time remaining on the LCD status line.)

This feature should only be enabled if a display is available to show it, otherwise the extra commands are useless.


The firmware supports the ability to interact with the host and provide notifications and prompts for users on the host side.


The firmware can repeat sections of G-code marked with the M808 command when the firmware is running the print from an SD card. This is useful to reduce G-code size when repeating objects on belt printers.


The firmware can print from an SD Card (or USB Flash Drive). If this capability is absent, use SD commands to check for SD capability.


The firmware supports serial XON/XOFF handshaking.


The firmware supports enabling/disabling power with M80 and M81.


The firmware has thermal protection enabled. Hosts can use this item to warn users of a potential fire hazard.


The firmware supports turning the case lights on/off with M355 S1 and M355 S0. (May also support setting case light brightness with S values 2-255.)


The firmware supports Volumetric Extrusion with M200 T D.


The firmware supports single point Z probing with G30.