Yet another one of these surprise bugs: this G-code ...

G21
G90
G1 X5 F300
G1 Y9
G1 X0 Y0
M2

... moves the first two G1s fine, but the third one is crawling:

The graph is shortened, it continues at least 30 seconds at the same low speed (~10 mm/min). Verified on real hardware. The bug is odd, because it requires precisely G1 X5, G1 Y9. G1 X5, G1 Y10 works fine.

It also happens with a specific config.h, only, apparently heater definitions play a role. I'll push a branch with credentials in a few minutes.

Movements on the X and Y axes seem to work ok in the simulator, but movement on the E or Z axis do not appear to do anything. No trace output is shown for changing positions, and the step pins are not toggled for either axis.

PID debug output (M111 S1) was printing the errors as unsigned values, which led to https://github.com/Traumflug/Teacup_Firmware/blob/master/sersendf.c#L132

The Issue75 branch changes the arguments to 'int16_t' and 'int32_t'

There are issues with the endstops for Sanguinololu v1.2.

The M200 g-code does act correctly for the minumum endstops. 0 when not pressed and 1 when pressed. (microswitch)

The homing commands:
G161 X does not stop when endstop is pressed
G161 Y does not stop when endstop is pressed
G161 Z do work fine when endstop is pressed

The configuration file can be found at http://pastebin.com/55NeTpXp

When testing Teacup on a custom CNC, with ReplicatorG used for simple manual commands, I can get the machine to move an axis in one direction once (one "jog") but then must jog the other way to get the machine to move again. I'm not sure why I can't jog twice in one direction. This is true for all three axes of my three-axis mantis-derivative.

It seems that if I click jog in one direction multiple times, the machine will finally comply. Any thoughts on what this means?

Date 29/09/2012
Configuration;
Prusa Mendel
Parcan Hotend
5x 42BYGHW811 Stepper Motors
Mechanical Endstops (sorry Makerbot V1.2)
Mk2 Heatbed
Sanguinololu 1.3b (Fan Cooled, 12v off ATX PSU, 5V off USB)
ATX PSU 450w

Firmware;
triffid-Teacup_Firmware-be29ab6

Software;
kliment-Printrun-b6935b9
Slic3r
OS; Windows 7

Error Description;
Many people suggested it was an underloaded PSU, However I can manually set temp to 230/110c and reach and continue nudging axis around without bot hanging.
When starting a print the bot will appear to have become unresponsive indefinately! After Trial and error I have determined that when Gcodes are manually entered in the following order the issue is reproducable.
M104 S60 ; set temperature
M140 S40 ;set bed temp
M116
G90 ; use absolute coordinates
G21 ; set units to millimeters
G92 E0 ; reset extrusion distance
M82 ; use absolute distances for extrusion
M115

To shorten this down to
M116
M92 E0
I was using M115 to check if it responds.
I used putty to open a terminal to my bot and I was able to reproduce the error!

+++++++++++++++++
Config.h
+++++++++++++++++

/* Notice to developers: this file is intentionally included twice. */

/** \file
\brief Sanguinololu configuration.
*/

/*
CONTENTS

1. Mechanical/Hardware
2. Acceleration settings
3. Pinouts
4. Temperature sensors
5. Heaters
6. Communication options
7. Miscellaneous
8. Appendix A - PWMable pins and mappings

*/

/***************************************************************************\

•                                                                       *
  

• 1. MECHANICAL/HARDWARE *

•                                                                       *
  

  ***************************************************************************/

/*
Set your microcontroller type in Makefile! atmega168/atmega328p/atmega644p/atmega1280

If you want to port this to a new chip, start off with arduino.h and see how you go.

*/

if ! ( defined (AVR_ATmega644P) || defined (AVR_ATmega644PA) )

#error Sanguinololu has a 644P/644PA! set your cpu type in Makefile!

endif

/** \def F_CPU
CPU clock rate
*/

ifndef F_CPU

#define F_CPU   16000000UL

endif

/** \def HOST
This is the motherboard, as opposed to the extruder. See extruder/ directory for GEN3 extruder firmware
*/

define HOST

/** \def STEPS_PER_M
steps per meter ( = steps per mm * 1000 )

calculate these values appropriate for your machine

for threaded rods, this is
    (steps motor per turn) / (pitch of the thread) * 1000

for belts, this is
    (steps per motor turn) / (number of gear teeth) / (belt module) * 1000

half-stepping doubles the number, quarter stepping requires * 4, etc.

valid range = 20 to 4'0960'000 (0.02 to 40960 steps/mm)

all numbers are integers, so no decimal point, please :-)

*/

define STEPS_PER_M_X 80368

define STEPS_PER_M_Y 80368

define STEPS_PER_M_Z 3200000 //was 3333592

/// http://blog.arcol.hu/?p=157 may help with this one

define STEPS_PER_M_E 481760 //gen7 set to 96271??? Was 11036

/*
Values depending on the capabilities of your stepper motors and other mechanics.
All numbers are integers, no decimals allowed.

    Units are mm/min

*/

/// used for G0 rapid moves and as a cap for all other feedrates

define MAXIMUM_FEEDRATE_X 200

define MAXIMUM_FEEDRATE_Y 200

define MAXIMUM_FEEDRATE_Z 100

define MAXIMUM_FEEDRATE_E 200

/// used when searching endstops and as default feedrate

define SEARCH_FEEDRATE_X 50

define SEARCH_FEEDRATE_Y 50

define SEARCH_FEEDRATE_Z 50

// no SEARCH_FEEDRATE_E, as E can't be searched

/** \def SLOW_HOMING
wether to search the home point slowly
With some endstop configurations, like when probing for the surface of a PCB, you can't deal with overrunning the endstop. In such a case, uncomment this definition.
*/
// #define SLOW_HOMING

/// this is how many steps to suck back the filament by when we stop. set to zero to disable

define E_STARTSTOP_STEPS 20

/**
Soft axis limits, in mm.
Define them to your machine's size relative to what your host considers to be the origin.
*/

//#define X_MIN 0.0
//#define X_MAX 200.0

//#define Y_MIN 0.0
//#define Y_MAX 200.0

//#define Z_MIN 0.0
//#define Z_MAX 140.0

/** \def E_ABSOLUTE
Some G-Code creators produce relative length commands for the extruder, others absolute ones. G-Code using absolute lengths can be recognized when there are G92 E0 commands from time to time. If you have G92 E0 in your G-Code, define this flag.

This is the startup default and can be changed with M82/M83 while running.

*/
// #define E_ABSOLUTE

/***************************************************************************\

•                                                                       *
  

• 2. ACCELERATION *

•                                                                       *
  

• IMPORTANT: choose only one! These algorithms choose when to step, trying *

•        to use more than one will have undefined and probably          *
  

•        disastrous results!                                            *
  

•                                                                       *
  

  ***************************************************************************/

/** \def ACCELERATION_REPRAP
acceleration, reprap style.
Each movement starts at the speed of the previous command and accelerates or decelerates linearly to reach target speed at the end of the movement.
*/
// #define ACCELERATION_REPRAP

/** \def ACCELERATION_RAMPING
acceleration and deceleration ramping.
Each movement starts at (almost) no speed, linearly accelerates to target speed and decelerates just in time to smoothly stop at the target. alternative to ACCELERATION_REPRAP
*/

define ACCELERATION_RAMPING

/** \def ACCELERATION
how fast to accelerate when using ACCELERATION_RAMPING.
given in mm/s^2, decimal allowed, useful range 1. to 10'000. Start with 10. for milling (high precision) or 1000. for printing
*/

define ACCELERATION 1000.

/** \def ACCELERATION_TEMPORAL
temporal step algorithm
This algorithm causes the timer to fire when any axis needs to step, instead of synchronising to the axis with the most steps ala bresenham.

    This algorithm is not a type of acceleration, and I haven't worked out how to integrate acceleration with it.
    However it does control step timing, so acceleration algorithms seemed appropriate

    The Bresenham algorithm is great for drawing lines, but not so good for steppers - In the case where X steps 3 times to Y's two, Y experiences massive jitter as it steps in sync with X every 2 out of 3 X steps. This is a worst-case, but the problem exists for most non-45/90 degree moves. At higher speeds, the jitter /will/ cause position loss and unnecessary vibration.
    This algorithm instead calculates when a step occurs on any axis, and sets the timer to that value.

    // TODO: figure out how to add acceleration to this algorithm

*/
// #define ACCELERATION_TEMPORAL

/***************************************************************************\

•                                                                       *
  

• 3. PINOUTS *

•                                                                       *
  

  ***************************************************************************/

/*
Machine Pin Definitions
- make sure to avoid duplicate usage of a pin
- comment out pins not in use, as this drops the corresponding code and makes operations faster
*/

include "arduino.h"

/** \def USE_INTERNAL_PULLUPS
internal pullup resistors
the ATmega has internal pullup resistors on it's input pins which are counterproductive with the commonly used eletronic endstops, so they should be switched off. For other endstops, like mechanical ones, you may want to uncomment this.
*/

define USE_INTERNAL_PULLUPS

/*
user defined pins
adjust to suit your electronics,
or adjust your electronics to suit this
*/

define X_STEP_PIN DIO15

define X_DIR_PIN DIO21

define X_MIN_PIN DIO18

//#define X_MAX_PIN xxxx
//#define X_ENABLE_PIN xxxx
//#define X_INVERT_DIR

define X_INVERT_MIN

//#define X_INVERT_MAX
//#define X_INVERT_ENABLE

define Y_STEP_PIN DIO22

define Y_DIR_PIN DIO23

define Y_MIN_PIN DIO19

//#define Y_MAX_PIN xxxx
//#define Y_ENABLE_PIN xxxx
//#define Y_INVERT_DIR

define Y_INVERT_MIN

//#define Y_INVERT_MAX
//#define Y_INVERT_ENABLE

define Z_STEP_PIN DIO3

define Z_DIR_PIN DIO2

define Z_MIN_PIN DIO20

//#define Z_MAX_PIN xxxx

define Z_ENABLE_PIN DIO26

//#define Z_INVERT_DIR

define Z_INVERT_MIN

//#define Z_INVERT_MAX

define Z_INVERT_ENABLE

define E_STEP_PIN DIO1

define E_DIR_PIN DIO0

//#define E_ENABLE_PIN xxxx
//#define E_INVERT_DIR
//#define E_INVERT_ENABLE

define PS_ON_PIN DIO9

define STEPPER_ENABLE_PIN DIO14

define STEPPER_INVERT_ENABLE

//#define SD_CARD_DETECT DIO2
//#define SD_WRITE_PROTECT DIO3

/***************************************************************************\

•                                                                       *
  

• 4. TEMPERATURE SENSORS *

•                                                                       *
  

  ***************************************************************************/

/**
TEMP_HYSTERESIS: actual temperature must be target +/- hysteresis before target temperature can be achieved.
Unit is degree Celsius.
*/

define TEMP_HYSTERESIS 5

/**
TEMP_RESIDENCY_TIME: actual temperature must be close to target for this long before target is achieved

temperature is "achieved" for purposes of M109 and friends when actual temperature is within [hysteresis] of target for [residency] seconds

*/

define TEMP_RESIDENCY_TIME 60

/// which temperature sensors are you using? List every type of sensor you use here once, to enable the appropriate code. Intercom is the gen3-style separate extruder board.
// #define TEMP_MAX6675

define TEMP_THERMISTOR

// #define TEMP_AD595
// #define TEMP_PT100
// #define TEMP_INTERCOM
// #define TEMP_NONE

/***************************************************************************\

•                                                                       *
  

• Define your temperature sensors here. One line for each sensor, only *
• limited by the number of available ATmega pins. *

•                                                                       *
  

• For a GEN3 set temp_type to TT_INTERCOM and temp_pin to 0. *

•                                                                       *
  

• Types are same as TEMP_ list above - TT_MAX6675, TT_THERMISTOR, TT_AD595, *
• TT_PT100, TT_INTERCOM, TT_NONE. See list in temp.c. *

•                                                                       *
  

• The "additional" field is used for TT_THERMISTOR only. It defines the *
• name of the table(s) in ThermistorTable.h to use. Typically, this is *
• THERMISTOR_EXTRUDER for the first or only table, or THERMISTOR_BED for *
• the second table. See also early in ThermistorTable.{single|double}.h. *

•                                                                       *
  

  ***************************************************************************/

ifndef DEFINE_TEMP_SENSOR

#define DEFINE_TEMP_SENSOR(...)

endif

// name type pin additional
DEFINE_TEMP_SENSOR(extruder, TT_THERMISTOR, AIO7_PIN, THERMISTOR_EXTRUDER)
DEFINE_TEMP_SENSOR(bed, TT_THERMISTOR, AIO6_PIN, THERMISTOR_BED)

/***************************************************************************\

•                                                                       *
  

• 5. HEATERS *

•                                                                       *
  

  ***************************************************************************/

/** \def HEATER_SANITY_CHECK
check if heater responds to changes in target temperature, disable and spit errors if not
largely untested, please comment in forum if this works, or doesn't work for you!
*/
// #define HEATER_SANITY_CHECK

/***************************************************************************\

•                                                                       *
  

• Define your heaters here. *

•                                                                       *
  

• Currently, heaters work on PWM-able pins, only. See the end of this file *
• for PWM-able pin mappings. *

•                                                                       *
  

• To attach a heater to a temp sensor above, simply use exactly the same *
• name - copy+paste is your friend. Some common names are 'extruder', *
• 'bed', 'fan', 'motor', ... names with special meaning can be found *
• in gcode_process.c. Currently, these are: *
• HEATER_extruder (M104) *
• HEATER_bed (M140) *
• HEATER_fan (M106/M107) *

•                                                                       *
  

• A milling spindle can also be defined as a heater. Attach it to a *
• temperature sensor of TT_NONE, then you can control the spindle's rpm *
• via temperature commands. M104 S1..255 for spindle on, M104 S0 for off. *

•                                                                       *
  

  ***************************************************************************/

ifndef DEFINE_HEATER

#define DEFINE_HEATER(...)

endif

// name port
DEFINE_HEATER(extruder, PD5)
DEFINE_HEATER(bed, PD4)

/// and now because the c preprocessor isn't as smart as it could be,
/// uncomment the ones you've listed above and comment the rest.
/// NOTE: these are used to enable various capability-specific chunks of code, you do NOT need to create new entries unless you are adding new capabilities elsewhere in the code!
/// so if you list a bed above, uncomment HEATER_BED, but if you list a chamber you do NOT need to create HEATED_CHAMBER
/// I have searched high and low for a way to make the preprocessor do this for us, but so far I have not found a way.

define HEATER_EXTRUDER HEATER_extruder

define HEATER_BED HEATER_bed

/***************************************************************************\

•                                                                       *
  

• 6. COMMUNICATION OPTIONS *

•                                                                       *
  

  ***************************************************************************/

/** \def REPRAP_HOST_COMPATIBILITY
RepRap Host changes it's communications protocol from time to time and intentionally avoids backwards compatibility. Set this to the date the source code of your Host was fetched from RepRap's repository, which is likely also the build date.
See the discussion on the reprap-dev mailing list from 11 Oct. 2010.

Undefine it for best human readability, set it to an old date for compatibility with hosts before August 2010

*/
// #define REPRAP_HOST_COMPATIBILITY 19750101
// #define REPRAP_HOST_COMPATIBILITY 20100806
// #define REPRAP_HOST_COMPATIBILITY 20110509
// #define REPRAP_HOST_COMPATIBILITY

/**
Baud rate for the connection to the host. Usually 115200, other common values are 19200, 38400 or 57600.
*/

define BAUD 115200

/** \def XONXOFF
Xon/Xoff flow control.
Redundant when using RepRap Host for sending GCode, but mandatory when sending GCode files with a plain terminal emulator, like GtkTerm (Linux), CoolTerm (Mac) or HyperTerminal (Windows).
Can also be set in Makefile
*/
// #define XONXOFF

/***************************************************************************\

•                                                                       *
  

• 7. MISCELLANEOUS OPTIONS *

•                                                                       *
  

  ***************************************************************************/

/** \def DEBUG
DEBUG
enables /heaps/ of extra output, and some extra M-codes.
WARNING: this WILL break most host-side talkers that expect particular responses from firmware such as reprap host and replicatorG
use with serial terminal or other suitable talker only.
*/
// #define DEBUG

/** \def BANG_BANG
BANG_BANG
drops PID loop from heater control, reduces code size significantly (1300 bytes!)
may allow DEBUG on '168
/
// #define BANG_BANG
/* \def BANG_BANG_ON
BANG_BANG_ON
PWM value for 'on'
/
// #define BANG_BANG_ON 200
/* \def BANG_BANG_OFF
BANG_BANG_OFF
PWM value for 'off'
*/
// #define BANG_BANG_OFF 45

/**
move buffer size, in number of moves
note that each move takes a fair chunk of ram (69 bytes as of this writing) so don't make the buffer too big - a bigger serial readbuffer may help more than increasing this unless your gcodes are more than 70 characters long on average.
however, a larger movebuffer will probably help with lots of short consecutive moves, as each move takes a bunch of math (hence time) to set up so a longer buffer allows more of the math to be done during preceding longer moves
*/

define MOVEBUFFER_SIZE 8

/** \def DC_EXTRUDER
DC extruder
If you have a DC motor extruder, configure it as a "heater" above and define this value as the index or name. You probably also want to comment out E_STEP_PIN and E_DIR_PIN in the Pinouts section above.
*/
// #define DC_EXTRUDER HEATER_motor
// #define DC_EXTRUDER_PWM 180

/** \def USE_WATCHDOG
Teacup implements a watchdog, which has to be reset every 250ms or it will reboot the controller. As rebooting (and letting the GCode sending application trying to continue the build with a then different Home point) is probably even worse than just hanging, and there is no better restore code in place, this is disabled for now.
*/
// #define USE_WATCHDOG

/**
analog subsystem stuff
REFERENCE - which analog reference to use. see analog.h for choices
*/

define REFERENCE REFERENCE_AVCC

/** \def STEP_INTERRUPT_INTERRUPTIBLE
this option makes the step interrupt interruptible (nested).
this should help immensely with dropped serial characters, but may also make debugging infuriating due to the complexities arising from nested interrupts
\note disable this option if you're using a '168 or for some reason your ram usage is above 90%. This option hugely increases likelihood of stack smashing.
*/

define STEP_INTERRUPT_INTERRUPTIBLE 1

/**
temperature history count. This is how many temperature readings to keep in order to calculate derivative in PID loop
higher values make PID derivative term more stable at the expense of reaction time
*/

define TH_COUNT 8

/** \def FAST_PWM
Teacup offers two PWM frequencies, 76(61) Hz and 78000(62500) Hz on a
20(16) MHz electronics. The slower one is the default, as it's the safer
choice. Drawback is, in a quiet environment you might notice the heaters
and your power supply humming.

Uncomment this option if you want to get rid of this humming or want
faster PWM for other reasons.

See also: http://reprap.org/wiki/Gen7_Research#MOSFET_heat_and_PWM

*/
// #define FAST_PWM

/// this is the scaling of internally stored PID values. 1024L is a good value

define PID_SCALE 1024L

/** \def ENDSTOP_STEPS
number of steps to run into the endstops intentionally
As Endstops trigger false alarm sometimes, Teacup debounces them by counting a number of consecutive positives. Valid range is 1...255. Use 4 or less for reliable endstops, 8 or even more for flaky ones.
*/

define ENDSTOP_STEPS 4

/***************************************************************************\

•                                                                       *
  

• 8. APPENDIX A - PWMABLE PINS AND MAPPINGS *

•                                                                       *
  

•                                                                       *
  

• list of PWM-able pins and corresponding timers *
• timer1 is used for step timing so don't use OC1A/OC1B *
• they are omitted from this listing for that reason *

•                                                                       *
  

• For the atmega168/328, timer/pin mappings are as follows *

•                                                                       *
  

• OCR0A - PD6 - DIO6 *
• OCR0B - PD5 - DIO5 *
• OCR2A - PB3 - DIO11 *
• OCR2B - PD3 - DIO3 *

•                                                                       *
  

• For the atmega644, timer/pin mappings are as follows *

•                                                                       *
  

• OCR0A - PB3 - DIO3 *
• OCR0B - PB4 - DIO4 *
• OCR2A - PD7 - DIO15 *
• OCR2B - PD6 - DIO14 *

•                                                                       *
  

• For the atmega1280, timer/pin mappings are as follows *

•                                                                       *
  

• OCR0A - PB7 - DIO13 *
• OCR0B - PG5 - DIO4 *
• OCR2A - PB4 - DIO10 *
• OCR2B - PH6 - DIO9 *
• OCR3AL - PE3 - DIO5 *
• OCR3BL - PE4 - DIO2 *
• OCR3CL - PE5 - DIO3 *
• OCR4AL - PH3 - DIO6 *
• OCR4BL - PH4 - DIO7 *
• OCR4CL - PH5 - DIO8 *
• OCR5AL - PL3 - DIO46 *
• OCR5BL - PL4 - DIO45 *
• OCR5CL - PL5 - DIO44 *

•                                                                       *
  

  ***************************************************************************/

temp_sensor_tick() does not need to call delay(1) to ensure a 100nsec delay. I debugged an issue with the Marlin firmware where the MAX6675 was read during an interrupt and this one msec delay would eventually cause Marlin to lock up when using the MAX6675. I scoped the SCLK and SS lines and the Atmel master is holding off SCLK 610nsec all by itself which satisfies the MAX6675 timing without any additional delay.

I highly recommend dropping the delay(1) line from temp_sensor_tick().

Just saw the uproar on IRC #reprap: "Teacup can never be compiled with Arduino IDE, because it's C and Arduino is G++ ... bla bla" ... one of the so-called "experts".

The real issue is: these three most recent commits to the Gen7 branch introduced some C99-only code, but Arduino insists on using C89. Can be easily fixed, but tomorrow is OS3DC in Frankfurt, so I can't fix it right now.

Another one is, it replaces a lot of space-indentation by tabs while I tried to get away from tabs over the last year. But that's minor.

As a quick band aid I moved these three commits to a new branch "roland" until I can review them.

That said, if this code holds what it promises, it's really great.

Building with HEATER_SANITY_CHECK defined fails with:

heater.c: In function ‘heater_tick’:
heater.c:320:141: error: ‘t’ undeclared (first use in this function)
heater.c:320:141: note: each undeclared identifier is reported only once for each function it appears in

Which is in:

268 #ifdef HEATER_SANITY_CHECK
269 // check heater sanity
270 // implementation is a moving window with some slow-down to compensate for thermal mass
271 if (target_temp > (current_temp + (TEMP_HYSTERESIS_4))) {
272 // heating
273 if (current_temp > heaters_runtime[h].sane_temperature)
274 // hotter than sane- good since we're heating unless too hot
275 heaters_runtime[h].sane_temperature = current_temp;
276 else {
277 if (heaters_runtime[h].sanity_counter < 40)
278 heaters_runtime[h].sanity_counter++;
279 else {
280 heaters_runtime[h].sanity_counter = 0;
281 // ratchet up expected temp
282 heaters_runtime[h].sane_temperature++;
283 }
284 }
285 // limit to target, so if we overshoot by too much for too long an error is flagged
286 if (heaters_runtime[h].sane_temperature > target_temp)
287 heaters_runtime[h].sane_temperature = target_temp;
288 }
289 else if (target_temp < (current_temp - (TEMP_HYSTERESIS_4))) {
290 // cooling
291 if (current_temp < heaters_runtime[h].sane_temperature)
292 // cooler than sane- good since we're cooling
293 heaters_runtime[h].sane_temperature = current_temp;
294 else {
295 if (heaters_runtime[h].sanity_counter < 125)
296 heaters_runtime[h].sanity_counter++;
297 else {
298 heaters_runtime[h].sanity_counter = 0;
299 // ratchet down expected temp
300 heaters_runtime[h].sane_temperature--;
301 }
302 }
303 // if we're at or below 60 celsius, don't freak out if we can't drop any more.
304 if (current_temp <= 240)
305 heaters_runtime[h].sane_temperature = current_temp;
306 // limit to target, so if we don't cool down for too long an error is flagged
307 else if (heaters_runtime[h].sane_temperature < target_temp)
308 heaters_runtime[h].sane_temperature = target_temp;
309 }
310 // we're within HYSTERESIS of our target
311 else {
312 heaters_runtime[h].sane_temperature = current_temp;
313 heaters_runtime[h].sanity_counter = 0;
314 }
315
316 // compare where we're at to where we should be
317 if (labs((int16_t)(current_temp - heaters_runtime[h].sane_temperature)) > (TEMP_HYSTERESIS_4)) {
318 // no change, or change in wrong direction for a long time- heater is broken!
319 pid_output = 0;
320 sersendf_P(PSTR("!! heater %d or temp sensor %d broken- temp is %d.%dC, target is %d.%dC, didn't reach %d.%dC in %d0 millis econds\n"), h, t, current_temp >> 2, (current_temp & 3) * 25, target_temp >> 2, (target_temp & 3) * 25, heaters_runtime[h].sane_temperature >> 2, (heaters_runtime[h].sane_temperature & 3) * 25, heaters_runtime[h].sanity_counter);
321 }
322 #endif /_ HEATER_SANITY_CHECK */

I guess t used to be defined. :-)

Having issues getting code for a fan to respond to gcode commands. Was previously using an older Teacup Commit and was able to easily switch on/off with M106/M107, by inserting
"DEFINE_HEATER(fan,AIO0)" and "#define HEATER_FAN HEATER_fan" into the config file and attaching the device to Analog 0. Since then I had to redo things and download the newer Teacup version. Thought it would be as easy as it was before, but haven't had any success yet. I'm using "DEFINE_HEATER(fan, AIO0, 1)" and "#define HEATER_FAN HEATER_fan" and trying to turn it on/off with M106 S255/S0. Also tried using the preconfigured Extruder and Bed Heater pins and their respective gcodes. Nothing.
I need to use an older version of the Arduino IDE (0018), so perhaps there is an issue there. All I am trying to do is turn 5 volts on and off, using a simple gcode. Is there a better way of doing this with Teacup? Thank you for any advice/insight.

There is small error in home_y_positive() function in home.c file.

At line 157:
t.X = -1000000;
should probably be:
t.Y = -1000000;

I found an interesting problem with DDR registers - I'm during design new board for RepStrap orientated printer without arduino, which can make it cost effective. I am working with chip atmega168 (no arduino board). I started compiling firmware with avr-gcc with standard config file (config.h and arduino_168_328p.h). Communication with chip is successful, but I wasn't able to move axis. I checked STEP signal with oscilloscope - an amplitude about 3 volts and with high out impedance. It showed that pin is configured as input, and only pull-up resistor is being switched.
I finally set up bits manually everything became OK.
Interesting is fact that all h config files for me looks ok.
Thank you in advance for support.

Hi,
this is more a general question about who should change/fix ... I'm currently fixing ReplicatorG 0034 for RepRap5D driven hardware... And temperature readings is one of the issues...

if REPRAP_HOST_COMPATIBILITY >= 20110509

sersendf_P(PSTR("T:%u.%u"), temp_sensors_runtime[index].last_read_temp >> 2, c);

else

sersendf_P(PSTR("\nT:%u.%u"), temp_sensors_runtime[index].last_read_temp >> 2, c);

endif

ifdef HEATER_BED

uint8_t b = 0;
b = (temp_sensors_runtime[HEATER_BED].last_read_temp & 3) * 25;

sersendf_P(PSTR(" B:%u.%u"), temp_sensors_runtime[HEATER_BED].last_read_temp >> 2 , b);

endif

RepG wants the temperature beeing reported as one line ... that means after the ok, whereas teacup (normally) reports it with a newline after the ok.

Is there a definition which states which reporting is okay? A standard :-) ? Anyway, from my first sight, I would vote for the first version... that means everything in one line? Are there any reasons why it should be different?
In the end, should one fix replicatorG, fix teacup or adapt both?

Thx...

You can find my patched version at github https://github.com/RobertFach/ReplicatorG

The G-code run in the in the picture is "straight-speeds.gcode". While the first two trapezoids move back and forth, trapezoids 3, 4 and 5 should be joined and not stop in between.

Steps to get the above picture:

cd testcases
./run-in-simulator.sh straight-speeds.gcode
gtkwave straight-speeds.processed.vcd

To get such an analog view, drag the signal over into the Signal column, then

• (important!) left click to select it
• right click -> Data Format -> Analog -> Step
• right click -> Data Format -> Analog -> Resizing -> All Data
• right click -> Insert Analog Height Extension.

Hi guys,

It looks like there is some kind of race condition occurring when homing to the min limit switches.

I have the switches setup as recommended, tied to ground trough the NC side, with pullups enabled on the input pins non inverting. The soft limits are not enabled.

What happens is this:

• powering up
• moving the axis 10 mm
• hit home axis
• the axis moves towards the limit switch correctly
• movement stops just before hitting the limit switch - at this point Teacup considers itself at 0 (i think)
• the axis will not move unless I manually trigger the limitswitch

Now if I reset and move the switch let's say 1 mm in the positive direction it will home correctly, hitting the switch and backing up just as it is supposed to .... but this only lasts until the next reset.

So I guess what happens is that the switch is expected to be on the positive side of 0 (let's say 1) but I would expect it not to mater as long as we have a limit switch.

Is this behavior intended?

This isn't an issue, more a blackboard to announce general achievements and changes.

Commenting out all the soft limits in config.h causes home.c to die.

This G-code (run with STPES_PER_M_X = 80000):

G21
G90
G1 X5 F400
G1 X0
G1 F200
G1 X10
G1 F400
G1 X20
G1 X20.001
G1 X20.002
G1 X20.003
G1 X25
G1 X0

Breaks lookahead:

Trapezoids 3, 4 and 5 should be joined. As you can see, a single G1 F400 causes a full stop (between Tr. 3 and 4) as well as very short moves (between Tr. 4 and 5). These moves are short enough to not cause a motor step.

Hi,

I recognized a strange behavior regarding negative acceleration (braking) on latest teacup firmware and Gen7 board. My steppers run with microstepping set to 8 and 16. Thats why I had to setup the steps_per_mm to reasonable large values. However, If I do so without reducing the maximum feed rate, the steppers will accelerate until the reach their maximum speed, after that, they will noticeable start to deaccelerate but with a much lower rate than the acceleration. And further it seems that they never reach the target because the deacceleration starts to early and with a too high rate.

The "problem" can be reproduced by setting the steps_per_mm value to a large value in the range (say 2-3k) for example and by setting the maximum feed rate to a value that is as large as possible (given by the steppers and controller; steppers must not loose steps).

My guess is that it could be an overflow or another special case that hasnÄt been considered. If you could point me to the corresponding code and comment on my issue (give a guess) I could also have a look at the code.

Thx

i am using grbl it works. and i am appreciative. I have looked at marlin and i get no response to my inquiry's. so i move on. i am not a fan of a cnc controller shield board. it is for some. i respect that. i am running a ardunio mega and four a4988 stepper controllers. i have bread boarded the stepper controllers i am running the black version. It seems a waste to me that their is not some movement of software to using the ms1, ms2, ms3 on the boards. from my way of thinking it would be a bug increase in speed. i am also looking for a encoder on the x,y,z, drives. I recognize that good tight code in a small package is preferred. and i am willing to modify that to some degree. is teacup moving that way or is this for the uno.

I have been experimenting with the LOOKAHEAD feature and found a stability issue in the RAMPING algorithm. It goes quickly wrong with LOOKAHEAD enabled in my tests : after a few non trivial crossing speeds have been computed it produces some extremely slow moves.

I traced back the problem to the move_state.c variable which seems to accumulate errors. Reinitializing the move_state.c and move_state.n variables (or recomputing them from scratch when LOOKAHEAD produces non 0 crossing speeds) before each move solves the problem.

I have been using TeaCup for a while and I never noticed similar issues with regular RAMPING code (maybe the symmetry of the ramps makes errors null in average).

Trying the simulator today, I found it to fail pretty quickly ... often after as short as 1 or 2 seconds after sending a G-code command. Diagnosis: output of steps simply hangs.

After some back and forth, I managed to find a workaround: e3f7cab

schedule_timer() is called with zero, which can't work for obvious reasons.

@phord, do you have insight wether this is sane or does the fix just cover a real bug?

Jerk is defined as the change in acceleration over a time period. It is the derivative of acceleration. That is, jerk = da/dt.

The units should be given in distance/(time^3).

http://en.wikipedia.org/wiki/Jerk_(physics)

Teacup now has jerk limits, but these are more correctly called "burst acceleration" since they give a max allowed velocity change due to move joining. Changes in velocity are called "acceleration", and acceleration is the derivative of velocity. Teacup's "jerk" limits are given in mm/min which is appropriate for velocity. I think this is treated as "velocity per move-join-period"; if so it appears to be a soft acceleration value since the "move-join-period" (which is our 'dt') is not pre-determined.

This softness may cause some ambiguity in these jerk limits, even if it is considered as a velocity limit, since the join period is unconstrained and may vary. If so, an appropriate jerk-limit for some moves may be too big for some other moves.

If the jerk limit is given in correct units (time-cubed), this ambiguity can be resolved by considering the time required for the direction change. But since it is already two orders incorrect (distance/time rather than distance/time^3) it may be more complicated than that.

If the correct units can be used now, though, they will not have to be replaced (or duplicated) when jerk-limits for different purposes are needed.

hello,

the problem is there is no way i can get the measurement running with my Gen7 v1.2 board and teacup-firmware.
things i´ve done:

measured the resistance of the ntc: about 100k seems ok and its changed when getting warmer/colder
measured the voltage of the ntc: about 5V changed when getting warmer/colder
changed microcontroller
uploaded repetier and suddenly i get a working temprature measurement.
reupload teacup -> temperature read out 0

thermistor settings in the config.h:
"#define TEMP_THERMISTOR
.
.
.

ifndef DEFINE_TEMP_SENSOR

#define DEFINE_TEMP_SENSOR(...)

endif

// name type pin additional
DEFINE_TEMP_SENSOR(extruder, TT_THERMISTOR, PINA1, THERMISTOR_EXTRUDER)
//DEFINE_TEMP_SENSOR(bed, TT_THERMISTOR, PINA2, THERMISTOR_BED)" (no bed attached)

tried many different thermistortables.h, but still no read out

Thanks for the very good help! appreciate it much!

reprap_nbg

@zuzuf, @Cyberwizzard, this extensive jerk calculation algorithm was and is a bit a thorn in my eye since I had a first look at GRBL and I thought a lot about getting this simplified. Here's the result of these considerations:

Foundation

• There is no need for extensive trigonometry, because we can handle each axis individually. On Mendel-like printers even more than on traditional concepts, because moving the mass of the X axis doesn't influence moving the mass of the Y axis at all.

• What we want to compute is actually not some complex corner angle <-> speed relationship, but the difference of speeds of each axis between two moves. Like:

  vx1 = 400 mm/min, vx2 = 420 mm/min  ==> continue full speed
  vx1 = 50 mm/min, vx2 = 600 mm/min ==> too much jerk ==> slow down
  

Math

What we want is (for each axis):

|v1 - v2| < max_jerk

In case this isn't satisfied, we can slow down by some factor x until the equitation is satisfied:

x * |v1 - v2| < max_jerk

Now computation is pretty straightforward:

     max_jerk
x = -----------
     |v1 - v2|

if x > 1: continue full speed
if x < 1: v = v_max * x

(Pseudo-)Code:

max_speed_factor = 2 << 8;
for (i = 0; i < AXIS_NUM; i++) {
  factor = (max_jerk(i) / abs(v1(i) - v2(i))) << 8
  if (factor < max_speed_factor)
    max_speed_factor = factor;
}
if (max_speed_factor >= (1 << 8))
  f_corner = f_max;
else
  f_corner = (f_max * max_speed_factor) >> 8

What do you think? Will this work? Does this reflect physics?

The only issue I can find so far is, computing speeds of both moves for each individual axis requires no less than eight 32-bit divisions.

There is small error in home_y_positive() function in home.c file.

At line 157:
t.X = -1000000;

I suspect this is probably a configuration issue, but I'm currently having a very strange issue with 1382274 whereby any negative move of the E axis causes the DDA to step the motor very quickly backwards for a fraction of a second or so, followed by a long, slow backwards movement which does not terminate. I suspect this has something to do with it,

M111 S2
ok
G1 E2
{DDA_CREATE: [0,0,0,2000] [ts:1540,ds:2000] }
ok
G1 E-2
{DDA_CREATE: [0,0,0,-2000] [ts:4294965756,ds:2000] }

At this point the E axis is moving slowly backwards, requiring a reset to stop. Judging by the ts field, it seems something must have wrapped?

Can't get the firmware to be recognized by usb after compiled and uploaded?

Posting this so it won't get forgotten, see http://forums.reprap.org/read.php?147,181541,181766#msg-181766

I'm having an issue compiling it in Arduino though

I get this:
dda_lookahead.c: In function 'dda_join_moves':
dda_lookahead.c:219: error: 'for' loop initial declaration used outside C99 mode
dda_lookahead.c:461: error: redefinition of 'sreg_save'
dda_lookahead.c:219: error: previous definition of 'sreg_save' was here
dda_lookahead.c:461: error: redefinition of '__ToDo'
dda_lookahead.c:219: error: previous definition of '__ToDo' was here
dda_lookahead.c:461: error: 'for' loop initial declaration used outside C99 mode

Cyberwizzards fork is here: https://github.com/Cyberwizzard/Teacup_Firmware

Hi,
I have recently configured Teacup Firmware to work on Arduino Uno with 4 Pololu stepper drivers, but how to set Teacup to be used on Delta Printer?
Is there any implementation of Delta Kinematics in code or I have to fork it on my own?

Just added a testcase in the tescases folder with a G-code file which apparently can't be handled by Teacup. Shortening these 10 digits left to the decimal to 3 makes it working.

Look like the simulator doesn'T like the code I just committed onto the cross branch:

$ gdb --args ./sim testcases/straight-speeds.gcode --tracefile=straight.trace --time-scale=0 --gcode 
[...]
(gdb) run
Starting program: /home/mah/RepRap/Teacup_Firmware/./sim testcases/straight-speeds.gcode --tracefile=straight.trace --time-scale=0 --gcode
timer_init: warp-speed
opening testcases/straight-speeds.gcode
analog_init: not implemented in simulator
start
ok
[...] 
G90
ok 
ok 
G1 X5 F400
ok 

Program received signal SIGSEGV, Segmentation fault.
[...]
(gdb) bt
#0  0x000000000040146d in dda_create (dda=0x608388 <movebuffer+104>, target=target@entry=0x6089b8 <next_target+8>) at dda.c:94
#1  0x00000000004024d9 in enqueue_home (t=0x6089b8 <next_target+8>, endstop_check=<optimized out>, 
    endstop_stop_cond=<optimized out>) at dda_queue.c:124
#2  0x000000000040310c in enqueue (t=<optimized out>) at dda_queue.h:36
#3  process_gcode_command () at gcode_process.c:626
#4  0x0000000000402a78 in gcode_parse_char (c=240 '\360') at gcode_parse.c:351
#5  0x0000000000400fa2 in main (argc=<optimized out>, argv=<optimized out>) at mendel.c:258
(gdb) list
89    #ifdef LOOKAHEAD
90    // Number the moves to identify them; allowed to overflow.
91    static uint8_t idcnt = 0;
92    static DDA* prev_dda = NULL;
93  
94    if (prev_dda->done || dda->waitfor_temp)
95      prev_dda = NULL;
96    #endif
97  
98    if (dda->waitfor_temp)
(gdb) 

When trying the simulator today I found it can't do sequences (sent manually, waiting in between) as simple as:

G1 X1
G1 X0

Doing so, the first line works fine, but on the second line, the X stepper doesn't stop at X = 0, but moves into negative space infinitely instead.

Motion for homing with the endstops does not use DDA and therefore doesn't use acceleration. This causes motors to stall when starting with even moderate feedrates.

Hello everybody,
can somebody help me, what and how setup for use teacup fw suitable for simple 3d cnc milling? only x/y/z axes - no spindle speed, directions... totaly simple

I think that I can't user it becase temp. checking...

thank you for all ideas

I am working on the movement code in dda.c and I discovered that the rampup_steps value (and rampdown) was completely wrong. After working my way back to where it was calculated, I got stuck on the calculation in the original source.

So I replaced that one with my own, with comments explaining how I got to it (and as such, why its correct).

I'm new to github so I didn't manage to figure out how to send a pull request for that single commit so here is a link to the changeset (note that the line numbers differ from your current master):
Cyberwizzard@4860a1a

I've mentioned this earlier already, but it's apparently totally unrelated to issue #65:

This is current issue-65 branch, the junction of these two lines in straight-speeds.gcode:

G1 X10 Y10 F200
G1 X20 Y20 F400

When ACCELERATION is 10, we seem able to accelerate up to our target speed without fail. When ACCELERATION is 100 or more, our maximum speed is much lower than the target speed and is spiky.

Here's a graph of our measured velocity for this script at several different ACCELERATION values:

G1 X30 F300
G1 X60 F300
G1 X90 F300
G1 X120 F300
G1 X150 F300
G1 X180 F300
M2

When lookahead is turned on, it seems to work ok for moves after the 2nd one. But the target speed is still unreached and the moves are still spiky.

Date 30/09/2012
Configuration;
Prusa Mendel
Parcan Hotend
5x 42BYGHW811 Stepper Motors
Mechanical Endstops (sorry Makerbot V1.2)
Mk2 Heatbed
Sanguinololu 1.3b (Fan Cooled, 12v off ATX PSU, 5V off USB)
ATX PSU 450w

Firmware;
triffid-Teacup_Firmware-be29ab6

Software;
kliment-Printrun-b6935b9
Slic3r
OS; Windows 7

enabling #define SLOW_HOMING in Config.h causes just X axis or 1 axis to home.

Here's a patch improving fan support for nickoe. Basically, he stumbled on how to define the thing in config.h, with thermistor type TT_NONE etc. Now he uses heater_set() instead fo temp_set().

diff --git a/gcode_process.c b/gcode_process.c
index d1c8c62..fb7a907 100644
--- a/gcode_process.c
 +++ b/gcode_process.c
 @@ -508,9 +508,9 @@ void process_gcode_command() {
            case 106:
                //? --- M106: Fan On ---
                //?
 -              //? Example: M106
 +              //? Example: M106 S255 
                //?
-               //? Turn on the cooling fan (if any).
+               //? Turn on the cooling fan (if any) at the rated speed
                //?

                #ifdef ENFORCE_ORDER
@@ -518,7 +518,16 @@ void process_gcode_command() {
                    queue_wait();
                #endif
                #ifdef HEATER_FAN
-                   heater_set(HEATER_FAN, 255);
+                   if ( ! next_target.seen_S) // Abort if no S parameter 
+                       break;
+                   if ( next_target.seen_P) // Abort if P paramter specefied (it should not be there)
+                       break;
+                   if (next_target.S > 255) // So there is no error when using larger values
+                       next_target.S = 255;
+                   temp_set(HEATER_FAN, next_target.S*4); // using temp_set instead of heater_set(), probably a bad idea, but hey it works. (it even contains a magic number)
+                   if (next_target.S)
+                       power_on();
+                   break;
                #endif
                break;

@@ -536,7 +545,7 @@ void process_gcode_command() {
                    queue_wait();
                #endif
                #ifdef HEATER_FAN
-                   heater_set(HEATER_FAN, 0);
+                   temp_set(HEATER_FAN, 0);
                #endif
                break;

DaveX aka. drf aka. drf5n has uploaded his branch for the Teensy 3.0: http://forums.reprap.org/read.php?146,195325,199577#msg-199577 Great work!

I had a look into this and see a lot of commits duplicating commits already on the master branch. These could vanish by rebasing this branch to more recent commits of the master, or even Gen7 branch. Rebasing would also allow a better overview of what actually makes the Teensy support.

Are you fine with me doing this rebasing, David? The code at the top of the teensy3 branch wouldn't change, but before pushing, you'd have to follow upstream first, like:

git pull

in case you're already on the teensy3 branch, or

git pull
git checkout teensy3
git rebase origin/teensy3

in case you were elsewhere. If you have different ideas, I'm all open. :)

G-code is testcases/short-moves.gcode, the result speaks for its self:

Whenever I use the P parameter for M-code such as M104 or M109, the two temperature readings being reported by Pronterface are the same, even though the printer is functioning properly and the bed is at about 60C and the hot end is at about 185C.

Now I use M104 S195 and M140 S60, followed by M116 to start a print.

But previously I used something like this:

M109 P1 S60
M109 P0 S195

And because I was doing this by hand, sometimes I would switch the order of the heaters and I found that whichever heater I called last would be the one whose temperature was reported for both readings. Also, maybe in the comments in gcodeprocess.c it could be explained how the P parameter works, because I did not know that if I had this start code:

M109 P1 S60
M109 S195

That my bed would be set to 195 because, while the default P is set to P0, once it is used, the default is set to the last used heater.

Commit 2013eff will not compile. make gives error in analog.c:85 - MUX5 not declared (first use in this function).

The %x formatting specifier is broken, producing unexpected output. This appears to be caused by an attempt to write the string "0x" to before formatting the hexadecimal integer,

    case 'x':
        serial_writestr_P(str_ox);
        if (j == 4)
            serwrite_hex32(va_arg(args, uint32_t));
            ...

Commenting the first serial_writestr_P() line causes things to behave as they
should.

the code in analog.c assumes that ADC channel # == pin # and fills analog_mask by using pin number:

  analog_mask = 1 << (pin)

For example, in atmega2560, ADC0 is located in pin PINF0.
This assumption is false for ADC channels 8-15, as they are located in different port, ADC channel 8 is in PINK0, so the analog_mask gets invalid pin mask.

RAMPS uses analog inputs 13-15 (PINK5 - PINK7) as thermistor inputs so this prevents Teacup from working properly with RAMPS.

I have Teacup running in SimulAVR. Took me quite some hacking on "foreign" code, 40598, 40638, 40594 and a few others, but I'm there, steppers run (invisibly):

src/simulavr -v -f ../Teacup_Firmware/build/teacup.elf
MESSAGE File to load: ../Teacup_Firmware/build/teacup.elf
MESSAGE Device name is atmega644
MESSAGE Connecting pin D1 as serial out to file - at 19200 baud.
MESSAGE Connecting file - as serial in to pin D0 at 19200 baud.
MESSAGE Running with CPU frequency: 20.000 MHz (20000000 Hz)
start
ok
M114
ok X:0.000,Y:0.000,Z:0.000,E:0.000,F:0
G1 X20 F200
ok 
M114
ok X:3.208,Y:0.000,Z:0.000,E:0.000,F:200
M114
ok X:13.069,Y:0.000,Z:0.000,E:0.000,F:200
M114
ok X:20.000,Y:0.000,Z:0.000,E:0.000,F:200
^C
SystemClock::Endless stopped
number of cpu cycles simulated: 372129894

Now it's almost trivial to attach with a debugger: http://reprap.org/wiki/SimulAVR#Attaching_a_debugger

Next step on the plan is to make pin signals visible, of course. Support is there, just very well hidden (they expect to write a Python wrapper application just to access the modules).

The default PID parameters are assigned around https://github.com/Traumflug/Teacup_Firmware/blob/master/heater.c#L79 it might be nicer to move these out to config.h, or use some optional overrides like PID_I_PARAMETER, etc., in config.h.

Also, it seems that the qs=250mS sampling period, qC=C/4 temperature resolution and TH_COUNT=8 combine to make the units of the PID parameters be:

P: counts/(PID_SCALE*e_qC)
I: counts/(PID_SCALE*(e_qC)*(qS))=counts/(PID_SCALE*e_qC*qs)
D: counts/(PID_SCALE*(e_qC)/(TH_COUNT*qs))

(where e_qC is the error in C/4, TH_COUNTS=8, and counts is the numerator of the PWM output power fraction or duty cycle (as in power=Watts*counts/255))

Interpreting the default {8125,512,24576} PID values in engineering units, these would be kP=32 counts/C, kI=8 counts/(C s), and kD=(194) counts/(C/s). Alternately, interpreting them as industrial PID controller or "Standard form" values: kP=32/255/C=12.5%FS/C, Ti=kP/kI=4s, and Td=kD/kP=6.0s.
(Edited to redefine things and move several terms and recalculate the values....)
I'd like to be able to:

1. Set the PID parameters in config.h,
2. Use some sort of consistent unit system.

The first seems straightforward: add PID_P, PID_I, PID_D, PID_I_LIM to config*.h and modify heater.c to use them if defined.

The second seems harder, in that I'd want the units and values in config.h and M136 report to be consistent with the parameter input commands M130, M131, M132, M133.

Thoughts?

Due to a missing const qualifier in extruder/ThermistorTable.h, the firmware doesn't compile on my system. The fix is simple:

diff --git a/createTemperatureLookup.py b/createTemperatureLookup.py
index 883486d..76aae9f 100755
--- a/createTemperatureLookup.py
+++ b/createTemperatureLookup.py
@@ -183,7 +183,7 @@ def main(argv):
                print "{ //" + " Table 0 chunk for B={b}, R0={r0}, R1={r1}, R2={r2}, Vref={v}".format(par="{",b=beta,r0=r0,r1=r1,r2=r2,v=vadc) 
        else:
                print "#define NUMTEMPS  %s " %  (len(adcs))
-               print "uint16_t temptable[NUMTEMPS][2] PROGMEM = {"
+               print "const uint16_t temptable[NUMTEMPS][2] PROGMEM = {"
        print "// {ADC, temp*%s }, // temp         Rtherm     Vtherm      resolution   power" % (mult)

        counter = 0
diff --git a/extruder/ThermistorTable.h b/extruder/ThermistorTable.h
index 4013b1a..32c1fad 100644
--- a/extruder/ThermistorTable.h
+++ b/extruder/ThermistorTable.h
@@ -24,7 +24,7 @@
 // max adc: 1023
 #define NUMTEMPS 20
 // {ADC, temp*4 }, // temp
-uint16_t temptable[NUMTABLES][NUMTEMPS][2] PROGMEM = {
+const uint16_t temptable[NUMTABLES][NUMTEMPS][2] PROGMEM = {
 {
    {1, 3364}, // 841.027617469 C
    {21, 1329}, // 332.486789769 C

The reprap host software cannot read the temperature readings which are sent as a response to m105 commands. This is because of a parsing issue, the host requires
"ok " followed by the response, whereas temp_print writes a newline between ok and temperature readings.

Fix:
Replace line
sersendf_P(PSTR("\nT:%u.%u"), temp_sensors_runtime[index].last_read_temp >> 2, c);
by
sersendf_P(PSTR("T:%u.%u"), temp_sensors_runtime[index].last_read_temp >> 2, c);

in temp.c in function temp_print()