Protocol Feature Negotiation

From RepRap
Jump to: navigation, search


This page describes a proposed feature negotiation protocol for firmware and hostware.

It works like this:

Host sends M115 to firmware. Firmware replies with FEATURES:0/feature0,1/feature1,2/feature2 Host works out which features it also supports. Assuming it supports feature0 and feature2 but not feature1, it calculates (1<<0) + (1<<2) = 5. Host sends M118 P5 to firmware.

This allows a non-linear feature set, and also allows firmwares and hostwares to negotiate the maximum set of combined features that they both support.

Simple firmwares can simply send a statically stored list, and more complex firmwares can build a list dynamically. The parsing and lookup is left to the host which has plenty of cycles to burn doing work like this, and the firmware receives a simple bitmask as a response which even the simplest of firmwares can easily handle. Host must use a 32 bit integer internally for the bitmask, firmware can choose an appropriate bit width for the number of features it supports.

The Generation N+1 electronics debacle has shown us clearly that linear versioning simply doesn't work in conjunction with reprap's bazaar-style development.

This feature negotiation (or something similar) is a prerequisite for Dual Band data exchange, and a simple launchpad for a large array of binary protocols.

Feature Name List

proposed list of feature names

  • dual-band - see Dual Band
  • accel-ramping - ramping acceleration
  • accel-reprap - reprap acceleration
  • accel-none - no acceleration
  • baud-change - allow baud change
  • sdcard-print - print from an sd card. firmware can either use the sd as a simple buffer, or implement a full filesystem.
  • sdcard-save - write to an sd card. firmware can either use the sd as a simple buffer, or implement a full filesystem.
  • sdcard-fileio - firmware supports multiple files on sd card, rather than a static single file or using sd as a raw block device buffer. Hostware should always provide a filename regardless. This is just a cue that hostware should expect to be able to write a new file and then load an older one, and that hostware can request a file list.
  • linenumbers-require - lines without a line number are rejected. If dual-band is enabled, this only applies to buffered commands
  • linenumbers-forceconsecutive - require consecutive line numbers. Prints must start at N1, go through N2, N3 etc. If dual-band is enabled, may only applies to buffered commands although firmware must accept both N1 G1 .. M105 .. N2 G1.. and N1 G1 .. N2 M105 .. N3 G1 ...
  • checksum-require - lines without a checksum are rejected
  • crc-v2 - "advanced" crc ala sjfw