The information on this page is not kept up to date, and will be removed in the future. Please see the google doc for a maintained version.

Sanguino3G Code

To make it easier for the microcontroller, ReplicatorG translates the somewhat convoluted G-Code into a binary code. The binary code is then either wrapped into blocks and sent to the Makerbot via the serial connection (38400 bps, 8n1), or written as raw binary data onto an SD Card to be picked up by the MCU.


A package is used to wrap every command. It ensures that the command received is complete and not corrupted. The package contains the following bytes:

  • 0: start byte, always 0xD5
  • 1: length of the packet, not including the start byte, length byte or the CRC.
  • 2: the command byte - this is the first byte of the payload
  • *: content of the block, all multibyte values are LSB first (Intel notation)
  • n-1: the package ends with a single byte CRC checksum of the payload (Maxim 1-Wire CRC)

(Tested and confirmed)

Binary data on SD Cards is not wrapped in those packages, but written out directly to the card.

Reply Packages

Reply packages are built just like the command packages. The first byte of the payload is the return code for the previous command (see Response Code below). All further bytes depend on the command sent.


Initialization is done by flushing all bytes from the serial line. Then we send a version request and wait up to 8 seconds for the reply package. If no reply comes, we try to reset the motherboard by pulsing RTS low. If we do get the expected reply, we check the reply code and verify the version number of the MakeBot.

Motherboard Codes

The motherboard understands the following codes. One letter represents one byte, so xxxx is a four-byte integer, vv is a two byte integer, etc. . 0x00 is the hexadecimal representation of a single byte.

  • 0: version
    • format: 0x00
    • reply: r vv (r = response code, v = motherboard version number times 100 (v1.23 returns 123))
  • 1: init
    • format: 0x01
    • reply: response code only
  • 2: get buffer size
    • reply: r ss (r = response code, s = size in bytes (256 for V1.6 firmware))
  • 3: clear buffer
    • (not used)
  • 4: get position
    • format: 0x04
    • reply: r xxxx yyyy zzzz ? (position in magic steps, ?=unknown additional byte)
  • 5: get range
    • reply: r ???? ???? ????
  • 6: set range
  • 7: abort: invalidate position, force reconciliation
    • format: 0x07 (no arguments)
  • 8: pause: toggles the "Pause" state
    • format: 0x08 (no arguments!)
  • 9: probe
    • format: 0x09 (???)
    • reply: r c (r = reply code, c = probe code (?))
  • 10: tool query
    • format: 0x0a … (followed by command to be sent to tool board, see below, also see 136: tool command)
  • 11: is finished: check if the previous command has been executed to the end
    • format: 0x0b
    • reply: r f (f = 0 if not yet finished)
  • 12: read eeprom
    • format: 0x0c oo n (o is the offset inside the EEPROM, n is the number of bytes to read)
  • 13: write eeprom
    • format: 0x0d oo n … (o is the offset inside the EEPROM, n is the number of bytes to write)
  • 14: capture to file (slow!)
    • format: 0x0e … 0x00 (… is a nul terminated filename in 8.3 format)
    • reply: SD card response code
  • 15: end capture
    • format: 0x0f
    • reply: response code only
  • 16: playback file
    • format: 0x10 … 0x00 (… is a null terminated filename in 8.3 format)
    • reply: SD card response code
  • 17: reset
    • format: 0x11
    • reply: r
    • not sure what the difference is to "init" (or does this reset "next filename" below?)
  • 18: next filename
    • format: 0x12 r (r = 1 for first filename, 0 for next filename)
    • reply: r s … 0 SD card response code, if main response code is "success", followed by nul-terminated text
    • (I could not get this to work…)
  • 129: queue point absolute
    • format: 0x81 xxxx yyyy zzzz mmmm (x, y, z are the position in magic units, m are micro steps)
    • corresponds to G1 X… Y… Z… F…
  • 130: set position registers
    • format: 0x82 xxxx yyyy zzzz
    • corresponds to G92 X… Y… Z…, but is also sent after every 0x81 command
  • 131: find axes minimum
    • format: 0x83 f mmmm tt (f is flags (1=x, 2=y, 4=z), m ist micro steps, t is timeout in seconds)
    • this is used to home the axes… .
  • 132: find axes maximum
  • 133: delay
    • format: 0x85 tttt (t is time in milliseconds)
  • 134: change tool
    • format: 0x86 t (t is tool index)
  • 135: wait for tool
    • format: 0x87 t dd cc (t is tool index, d is delay in milliseconds (100), c is timeout in seconds (120))
    • example: (0x86 0x00) 0x87 0x00 0x64 0x00 0x78 0x00 = wait for extruder to reach the preset temperature
  • 136: tool command
    • format: 0x88 t c p a (t is the toolhead, c is the tool command, p is the size of the argument list in bytes, and a are possible arguments, see also tool query, code 10)
  • 137: enable axes
    • format: 0x89 b (b is a bit field of axes, 7 changes all axes, bit 7 indicates on or off)

Toolhead Codes

The tool heads understand these codes (details needed):

  • 0: version
  • 1: init
  • 2: get temperature
    • format: 0x0a t 0x02 (t is toolhead index starting at 0)
    • reply: cc (c is temperature in Celsius)
    • (verified OK)
  • 3: set temperature
    • format: 0x88 t 0x03 n cc (t is toolhead, n is number of bytes following (2), c is the temperature)
    • corresponds to M104 Sccc
  • 4: set motor 1 pwm
    • format 0x88 t 0x04 n s (t is toolhead, n is number of bytes following, s is the speed)
    • corresponds to M108 Snnn
  • 5: set motor 2 pwm
  • 6: set motor 1 rpm
    • format 0x88 t 0x06 n rrrr (t is toolhead, n is number of bytes following, r is rpm in microseconds per pulse)
  • 7: set motor 2 rpm
  • 8: set motor 1 direction
  • 9: set motor 2 direction
  • 10: toggle motor 1
    • format: 0x88 t 0x0a n f (t is toolhead, n is bytes following, bit 0 of f is motor on or off, bit 1 is the direction)
    • corresponds to M101 and M103
  • 11: toggle motor 2
  • 12: toggle fan
    • format: 0x88 t 0x0c n f (t is toolhead, n is number of bytes following, f is flag: 1=on, 0=off)
    • corresponds to M106 and M107
  • 13: toggle valve
    • format: 0x88 t 0x0d n f (t is toolhead, n is number of bytes following, f is flag: 1=on, 0=off)
  • 14: set servo 1 pos
  • 15: set servo 2 pos
  • 16: filament status
  • 17: get motor 1 rpm
    • format: 0x10 t 0x11
    • return: rrrr (r is rpm in micros)
  • 18: get motor 2 rpm
    • format: 0x10 t 0x12
    • return: rrrr (r is rpm in micros)
  • 19: get motor 1 pwm
    • format: 0x10 t 0x13
    • return: p (p is pwm)
  • 20: get motor 2 pwm
    • format: 0x10 t 0x14
    • return: p (p is pwm)
  • 21: select tool
  • 22: is tool ready

Magic Units

write this

Micro steps

write this


The EEPROM contains the following information:

  • 0-1: EEPROM data version
  • 2: axes inversion table
  • 32-47: machine name (ASCII, max. 16 chars)

Response Codes

Regular commands return these codes:

  • 0: generic error
  • 1: ok
  • 2: buffer overflow
  • 3: CRC mismatch (resulting code may be sent anyway! This is a bad idea because a CRC mismatch indicates a communication error, so the commend should not be executed, and the result is worthless)
  • 4: query overflow
  • 5: unsupported command

The SD card can return the following status bytes:

  • 0: success
  • 1: no card
  • 2: init failed
  • 3: partition not supported
  • 4: file system not supported
  • 5: root dir not found
  • 6: card locked
  • 7: no such file
Unless otherwise stated, the content of this page is licensed under GNU Free Documentation License.