
Although the TOM286 conversion won’t need any fancy firmware, I forked Marlin’s Github repository and created a TOM286 branch based on the Marlin_v1
branch for the Azteeg X3 modifications; in theory, we can blend in future Marlin updates without too much hassle.
The Pronterface serial port tops out at 115200, so that’s a mandatory change right up front. [grin]
Marlin has a motherboard definition for an Azteeg X3 (type 67
), but without the optional thermocouple inputs. I added motherboard 671
, following the lead of the Megatronics board definitions (types 70
, 701
, and 702
). In addition to the changes below, any test for motherboard 67
now includes 671
, as the other pins and suchlike (should) be the same.
Motherboard 671
selects new pin definitions for the temperature inputs in pins.h
:
#if MOTHERBOARD == 671 #define TEMP_0_PIN 11 // TC1 on shield #define TEMP_1_PIN 4 // TC2 on shield #define TEMP_2_PIN 13 // T0 thermistor on Azteeg X3 motherboard #else #define TEMP_0_PIN 13 // ANALOG NUMBERING #define TEMP_1_PIN 15 // ANALOG NUMBERING #define TEMP_2_PIN -1 // ANALOG NUMBERING #endif
There’s now a TCOUPLE_AMP_TYPE
definition in Configuration.h
to select AD595 or AD849x thermocouple interfaces:
// Thermocouple sensor amplifier type // 0 = AD595 gain = 10 mV/C // 1 = AD849[4567] gain = 5 mV/C #define TCOUPLE_AMP_TYPE 1
That picks the proper offset and gain definitions in Configuration_adv.h
:
// The AD849[4567] has 5 mv/C gain, half that of the AD595, and requires _GAIN = 2 #if TCOUPLE_AMP_TYPE == 1 #define TEMP_SENSOR_AD595_OFFSET 0.0 #define TEMP_SENSOR_AD595_GAIN 2.0 #else #define TEMP_SENSOR_AD595_OFFSET 0.0 #define TEMP_SENSOR_AD595_GAIN 1.0 #endif
With those in hand, these temperature sensor selections in Configuration.h
will work:
#define TEMP_SENSOR_0 -1 #define TEMP_SENSOR_1 0 #define TEMP_SENSOR_2 0 #define TEMP_SENSOR_BED 1
I tweaked the temperature limits and preheat settings; the absolute minimum temperatures are now 10 °C, although I have not verified that a disconnected thermocouple or thermistor will actually trip that limit.
Given the completely arbitrary stepper motor wiring connections, I set all the direction inversions to false
and then swapped wires to make the motors turn in the proper direction.
I enabled EEPROM_SETTINGS
, but haven’t verified that values can actually store and recall themselves.
The XYZ=0 origin is in the middle of the platform, just where I like it, but that will require some fine tuning:
// Travel limits after homing #define X_MAX_POS 55 #define X_MIN_POS -50 #define Y_MAX_POS 60 #define Y_MIN_POS -60 #define Z_MAX_POS 120 #define Z_MIN_POS 0
I think it’s possible to use the Z_SAFE_HOMING
position to force Z-minimum homing on the platform height switch I built for the original firmware, but that operation also seems to be tied in with the three-point auto-leveling firmware and rotating switch assembly. Right now, the firmware homes to the Z-max switch as a stock Thing-O-Matic should, but I’ve never liked that arrangement; don’t start with me, you know how I get.
I backed the speeds and accelerations down from the values I’d been using, mostly because the driver hardware and currents are different:
// Computing steps/mm // for XY = (motor steps/rev * microstepping) / (pulley teeth * tooth pitch) // for Z = (motor steps/rev * microstepping) / (screw lead) // for E = (motor steps/rev * microstepping) / (gear ratio * drive circumference) // make sure ratios use floating point to avoid integer division! #define DEFAULT_AXIS_STEPS_PER_UNIT {(200*16)/(17*2.0), (200*16)/(17*2.0), (200*8)/8.0, (200*4)/((7*30.23)/51)} #define DEFAULT_MAX_FEEDRATE {5000/60, 5000/60, 1500/60, 4000/60} // (mm/sec) #define DEFAULT_MAX_ACCELERATION {5000, 2500, 1000, 250} // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for skeinforge 40+, for older versions raise them a lot. #define DEFAULT_ACCELERATION 10000 // X, Y, Z and E max acceleration in mm/s^2 for printing moves #define DEFAULT_RETRACT_ACCELERATION 10000 // X, Y, Z and E max acceleration in mm/s^2 for retracts
I’m not sure how to calculate the “jerk” settings, but taken as the maximum un-accelerated speed, these seem conservative:
// The speed change that does not require acceleration (i.e. the software might assume it can be done instantaneously) #define DEFAULT_XYJERK 25 // (mm/sec) #define DEFAULT_ZJERK 5 // (mm/sec) #define DEFAULT_EJERK 5 // (mm/sec)
More tuning is in order; that should at least start it up.