Talk:G-code

M104 & M109 Deprecation, G10 Introduction

No issues with deprecating M109, as this is an equivalent to M104 & M116. But M104? [heated bed (M140) example deleted]

I consider G10 head/tool offset a good idea, but temperatures should be set by it's own command. Also, one often sets a temperature only, keeping the geometrical offset.

If the L value is ignored, why is it part of the specification?

Last not least, Marlin people already defined M206 for the head offset. These two should be aligned.

--Traumflug 11:28, 19 July 2012 (UTC)

M140 seems unaffected, Traumflug, so you can set the bed temp without changes. That said, I don't like any of this one bit. I don't like that the fast temp setting is gone, and I don't like that mysterious temperatures come out of nowhere when switching tool. I'd much prefer G10 to deal with spatial offset only, and use M10{4|9} [T0] S200. It gives the gcode generator much more control over the process. Having an OPTIONAL temperature setting in G10 would be acceptable for me, but definitely not deprecating M104/M109

--Kliment

I don't quite see why temperature offsets are different from spatial offsets - it's just another dimension in which the machine operates. It seemed neater to me to set them all in one place. And temperatures don't come out of nowhere - they are values you have previously explicitly set...

Jean-Marc pointed out that it would be useful to have an option to save and load this stuff from eeprom - that way you could have slightly different offsets for different machines and still run them all off the same G Code file.

I agree that M104 is useful as it allows you to do:

1. set temp and return
2. do stuff you know doesn't involve extruding
3. set same temp and wait

Which speeds things up a bit at the start of a print. I'm not quite sure what we should do about that.

As there is a standard (G10) for setting offset that pre-dates the invention of 3D printing, I think that's preferable to M206.

Finally - remember that the time interval between something being deprecated and something going away altogether can be arbitrarily long, and is entirely in the hands of people writing firmware :-)

- Adrian

Other stuff

Ah excellent, I've been waiting for this! I've been working from the gcode and mcode pages in the old wiki which have a few holes.

The line number and checksum stuff is new to me- I'll implement that into my firmware in the coming days. So are some of these M-codes for that matter.

Can we add some sort of reference for what the host expects in response from the firmware? So far, I'm sending back OK when the command is queued or executed and T: nnn every second when the heater is on, which as far as I can tell is all that's needed.

ps: why are G20/G21/G90/G91/G92 specified to block? ("The following commands are not buffered. When one is received it is stored, but it is not acknowledged to the host until the buffer is exhausted and then the command has been executed.") they simply alter the conversion factors for the next command received in my firmware, and so can respond OK immediately.

Only G4 (dwell) and M101 (start extruder when up to temperature, apparently superceded by the new M109) block in my firmware at the moment, and I'm seriously considering making even these queue-able so they block the queue instead of the command download stream.

-- Triffid Hunter

I agree. It's great for this to be documented.

I had one suggestion on the checksum -- it should perhaps use a stronger CRC checksum, and should also encorporate the length as well? Is the N and * part of an external standard, or a RepRap special sauce?

If they are RepRap specific, I'd suggest changing the N code to include line length as something like "N101.50" for line 101, consisting of 50 characters.

I use the following CRC algorithm, which I believe I stole from the CCITT standard:

static inline uint16_t GetCRC( uint16_t crc, char ser_data )
{
  crc  = (unsigned char)(crc >> 8) | (crc << 8);
  crc ^= ser_data;
  crc ^= (unsigned char)(crc & 0xff) >> 4;
  crc ^= (crc << 8) << 4;
  crc ^= ((crc & 0xff) << 4) << 1;
  return crc;
}

The logic to compute checksum would then become:

uint16_t cs = 0;
for(int i = 0; i < cmd.length(); i++)
  cs = GetCRC( cs, cmd.charAt(i) );

computedCrc = cs;

So, the full logic for accepting or testing a line, encoded with full N and CRC checksum would be something like:

// was line number and checksum provided?
bool value = true;
if( lineNumber != 0 )
{
  valid = lineNumber == expectedLineNumber
    && cmd.length() == providedLength
    && computedCrc == providedCrc;
}

// accept or reject the line based on valid flag

This does add a few bytes of overhead (3-4 for length, 2-3 for 16 bit crc), but may be worth it allows you to run a higher baud rate with reasonably low error rates -- the odds of a false positive are near enough to zero to make any statistician happy.

-- BeagleFury

Just wanted to chime in - Thanks Adrian! This answers many questions for me! -- Wade

what part of the line does cmd.length() refer to?

Just trying to implement the checksum logic, and realised that it makes no sense for the checksum to include itself or things get very recursive. What point is considered end-of-line? is it the asterisk? the space before the asterisk? the last non-whitespace before the asterisk?

My firmware doesn't buffer the line, rather processes it character by character so this has to become another special case.

-- Triffid Hunter

The checksum includes all characters in the string up to and including the character before the asterisk (i.e. up to but not including the asterisk). -- neilrqm

Future-proof M-codes?

Adding new M-codes for extra sensors/heaters seems a little non-future-proof to me. My firmware uses P parameter to know which sensor/heater is being referred to eg M104 S100 sets heater 0 to 100c, but M104 P2 S100 sets heater 2 to 100c. Same for all the temperature sensor readback stuff. Future proofing protocols is always a good idea :)

G91: Set to Relative Positioning

Example: G91 All coordinates from now on are relative to the last position.

Question: does this include the feed rate?

-- User:Pietr

M203: Record Z adjustment

which firmware does this?

Sprinter Main does not have M203 implimented Sprinter Experimental has M203 as "M203 Temperature monitor for Repetier" Repetier has M203 as Temperaturmonitor. Marlin has M203 - Set maximum feedrate that your machine can sustain (M203 X200 Y200 Z300 E10000) in mm/sec Teacup has no M203

Does any current or experimental firmware have the z adjustment implimented?

eMAKER Sprinter used this. but is now deprecated in favour of Marlin.

-- jmgiacalone