M-codes for EEPROM config
(This is proposed by AlexRa on 11-March-2011. I have a TechZone's Huxley with a somewhat modified firmware and going to add these commands to it. Then it probably shouldn't be very difficult to port the changes over to RepRap's mainstream firmware. The idea is very obvious and I'm sure other people thought about it before. If you know of a better / different way to do the configuration, please contribute).
- I think its a very good idea to save configuration values in EEPROM. The way I have implemented it is with some Mcodes to be able to set the parameters on the machine (currently M92 to set axis_step_per_unit (same syntax as G92) and M192 to set PID values), once they are good I use some Mcodes to save the values to EEPROM. This way I do not need separate commands and syntaxes to store each value. Just my 2 cents. --MrAlvin 12 April 2011
- Experience has shown that it can be equally important to be able to read these settings. I use M215 to echo values, one on each line, and in puTTY or RepSnappers communication log, I can then read them, and decide to re-use in new firmware or adjust up or down as changes to the machine dictates. --MrAlvin 12 April 2011
This page is intended as an extension of the GCode page and, if the proposed codes get accepted by the community, may be eventually merged into that page.
Contents
Motivation:
There is a number of physical parameters, such as steps-per-mm on the 3 axes and, especially, on the extruder, that normally require adjustment whenever a reprap is built, modified or the extruder hot-end replaced.
Currently, those parameters are constants hardcoded in the firmware. A user has to install a toolchain for the firmware modification and re-flashing (e.g. Arduino) and has to have at least some understanding of C programming to make the necessary adjustments.
However, every AVR MCU used in RepRap motherboards has persistent EEPROM memory where all such configurations can be conveniently saved.
Proposed solution:
The most obvious way to configure the settings is by some custom GCode commands. At the moment, M-commands in the range 250..255 seem to be available. Below is a proposed set of M-codes for writing persistent settings into the motherboard:
Command | Parameters | Action |
---|---|---|
M255 | [Xnn] [Ynn] [Znn] [Ennn] [Tn] | Steps per mm for the axes and the extruder.
The command writes only the specified axes, reports back all stored values in the "X: Y: Z: E:" format. If issued without any parameters, it just reports the current settings. The optional Tn parameter specifies the extruder to be set (on multiple-extruder repraps). If E is specified and T isn't, the extrusion rate is set for all available extruders (usually there is only one anyway). In the FiveD firmware, these settings should replace the X|Y|Z|E0|E1_STEPS_PER_MM constants in configuration.h. |
M254 | [Xn] [Yn] [Zn] | Set safe axes boundaries (build volume) in mm.
This is essential for printers with only one set of end-stops. Any movement beyond the defined boundaries should be blocked by the firmware. The command returns the current settings. |
M253 | [Xn] [Yn] [Zn] [En] [Tn] | Maximum speed (mm/sec) for any of the
axes and the extruder. Especially the limiting value for the extruder is important, because it is often the extruder speed that limits the printer performance. The command returns the current settings. |
M252 | [Sn] [Tn] | Set the max allowed temperature for the specified (or the default)
extruder. That makes sure that any wild temperature setting sent in GCode will be detected by the firmware and won't cause uncontrolled overheating. Without the S parameter, reports the current setting. |
M251 | [Sn] | Same as M252, but for the hot bed. This is particularly important,
as some known hot bed designs (e.g. PCB-based) are sensitive to overheating. |
M250 | [Zn] [S0/1] [G28] | "Z homing overshoot", in mm. There is currently no such parameter in the FiveD firmware.
The idea is that instead of carefully adjusting the Z opto stop, we set it slightly higher (1-3mm) than needed, then tell the printer how much it must move the head down after reaching the stop. This has 2 benefits: 1-st and most important, fine Z-adjustments can be done digitally without touching the opto and 2-nd, that the up-and-down homing motion is done at a safe distance from the plate (no more squeezing hot plastic all over the extruder tip). Such a command makes sense with or without actually writing the setting to EEPROM, so make the setting temporary by specifying 'S0'. The optional 'G28' (used as a parameter, which actually makes no difference for the parser) immediately does the homing, but only on the Z axis. |
M249 | [Xd] [Yd] [Zd] [Ed] | Reverses the direction of motion on any of the X/Y/Z/E axes. The d value must be either 0 or 1. This is the runtime equivalent of the INVERT_X/Y/Z/E_DIR constants in the FiveD firmware. |
Tip calibration codes
Those codes may be useful for PID calibration, assuming that the firmware controls the extruder temperature internally and has direct access to heater's PWM (as opposite to using a separate sub-controller):
Command | Parameters | Action |
---|---|---|
M245 | [Pn] | Set the head stabilization delay, in sec, as used by the M109 command. This allows the default delay of 40 seconds to be changed. |
M244 | PID [Pp] [Ii] [Rd] [Sb] [Xx] [Ti] | Set up (write to EEPROM) parameters for the PID algorithm. The GCode parser in the current FiveD firmware is somewhat limited in the parameter names, so the P.I.D. gains are specified as P, I and R parameters, the PID band is specified as the S parameter, and X sets the PWM increase while extruding. If any of these parameters are omitted, they remain unchanged. Whether it changes anything or not, the command responds with the current settings (after changes). The heaters may not be immediately affected; reset the device to make sure.
If there are several PID-controlled heaters, Ti tells which one we want to set up. Usually T0 (or default) would apply to the extruder (or all extruders), T1 would be the heated bed. A situation when a printer has several extruders with significantly different PID parameters is unlikely to happen and if it does, it would require changes to the firmware anyway. |
M243 | [Ti] Sn | Directly set PWM on the heater. The N is between 0.0 and 1.0 (or 0 and 100) and defines the PWM duty cycle.
The heater is turned on to the specified PWM. No temp control takes place in the firmware, except that the heater does get switched off if it reaches the max allowed temperature (see above). This command can be used either for calibration purposes (compute PID parameters on the host PC, write them to EEPROM with M248 described below), or if for some reason direct heater control is desirable. In either case, the host monitors temperatures using the regular M105 command. The optional T parameter may be used to specify the affected heater (there may be one or more extruders, heated bed, chamber, whatever). |
Thermistor profiles
There are many different ways to do temperature sensing in RepRaps. Some machines use external temperature controllers or use thermocouples with some cold-end conpensation circuitry. Each of these solutions do require special temperature reading code in the firware. However, it appears that simply using a thermistor is quite common. Any thermistor can be read using the same code, but requires a temperature table to correctly convert its resistance to temperature. With the official FiveD firmware, it is possible to choose the correct thermistor model at compile time, or add your own temptable. The proposed configuration commands below require some changes to the firmware, but allow to choose the correct thermistor type or define your own temperature table at GCode level, without reflashing your device:
Command | Parameters | Action |
---|---|---|
M240 | [Tn] Sm | Set the thermistor profile for heater Tn (N=0 is the default extruder, N=1,2... may be the heated bed, more extruders or whatever, machine specific). The Sm parameter specifies one of the thermistor profiles known to the firmware. (This feature assumes that more than one thermistor table is included in the compiled firmware and the table can be set at runtime, which is not how it's currently done in the official FiveD firmware). The profile numbers are from 1 to whatever number of thermistor tables are present in the firmware (about 6 at the time of writing this); S255 can be used to switch to the user-defined temp table stored in EEPROM (see below). This command can only be used to change the specific model of thermistor, but not to switch from some other sensor type to a thermistor (would report an error). |
M239 | Ii Xn Ym | Configure the EEPROM-based thermistor profile. The Ii parameter is the index of the table entry (0..19),
Xn and Ym specify the pair of values (ADC reading -> temperature) to be stored at this index. See Thermistor for more information on thermistor tables. To fully define a new thermistor table, a sequence of 20 such commands must be sent to the device. The EEPROM-based temp table can be activated using "M246 [Tn] S255" (see above). |
Baud rate control
Currently the baud rate for communicating with the host computer is hardcoded, being 19200 for most reprap variants. It is not clear if configuring it on-the-fly has some significant benefits or if it would conflict with the serial/USB interface IC. Apparently the commonly used FT232R IC communicates with the MCU at whatever baud rate is set to the driver on the host PC, so it should support speed changes easily.
Command | Parameters | Action |
---|---|---|
M238 | [Sn] | Set the host-comm baudrate to N, where N either selects from one of predefined rates (1 - 2400, 2 - 4800, 3 - 9600, 4 - 19200, 5 - 38400, 6 - 57600, 7 - 115200), or specifies one of those rates directly. E.g. both "M244 S19200" and "M244 S4" are allowed and mean the same thing. Specifying "S0" reverts to whatever default baud rate hardcoded into the firmware. Without the "S" parameter, "M244" only reports the current baud rate. If the speed is changed, the new value is written to EEPROM but is NOT applied until the device is reset, so the command does not break communications with the printer. |
Usage
For obvious reasons the commands above are not intended to be generated in the regular printing GCode. They are to be entered either manually or via some configuration UI utility on the host computer while calibrating the printer.