The New Hotness

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.