Thermocouple and M109 - Printer starts without waiting for temp

entr04y

I just added an ADAFruit breakout thermocouple to my system and updated my config using the website... downloaded the full firmware package of 0.92 with the new config on Saturday night. The thermocouple is on pin A3 on a ramps 1.4 board.

I'm getting good temperature readings for the extruder and everything seems to be working right, except that when I start a print with the following GCODE:

M107

G28; home all axes

G1 Z5; Raise 5

M109 S200

G21 ; set units to millimeters

G90 ; use absolute coordinates

M82 ; use absolute distances for extrusion

G92 E0

...

The printer homes, Goes to Z5, turns on the heater, and immediately starts the print. It's not waiting for temperature before starting. Is there another setting somewhere that I need to use to make it wait on the thermocouple temp? This wasn't happening when I was using a thermistor plugged into the normal pins.

Repetier

Strange thing. The routine does not differ between sensor types. It uses the the temperature returned which you see also in the host. Only wanted reason to exit is with SKIP_M109_IF_WITHIN but in your example it must be 180 and I doubt you have set it that high.

The routine that should do the heatup and waiting is in Extruder.cpp line 582

void Extruder::setTemperatureForExtruder(float temperatureInCelsius, uint8_t extr, bool beep, bool wait)

{

Could you add some

Com::printFLN(PSTR("pos 1"));

in that routine to see what is happening there. Important is the the loop

do { ---

Com::printFLN(PSTR("wait "),(long)waituntil); // add this as well

}

while(waituntil == 0 || (waituntil != 0 && (millis_t)(waituntil - currentTime) < 2000000000UL));

that should loop until temperature is reached. This is where you exit to early from your description. Hopefully that gives some insight what is going on.

entr04y

Ok, I just put the following in:

Line 643: Com::printFLN(PSTR("pos 1"));

Line 662: Com::printFLN(PSTR("pos 2"));

Line 675: Com::printFLN(PSTR("pos 3"));

Line 676: Com::printFLN(PSTR("wait "),(long)waituntil); // add this as well

When I ran the print (using repetier host) The log output contained

pos 1

pos 2

pos 3

pos 2

pos 3

pos 2

pos 3

and so on for a lot of lines (maybe 100 or more?)

pos 2

pos 3

printing layer 1 of 80

entr04y

BTW, EXT0 watchperiod is set to 1 and SKIP_M109 is set to 2

entr04y

Probably unrelated, but I am also having a couple other bits of weirdness going on... one is that when I start a print the printer homes and starts to move down to Z 5 and stops after moving down about 100mm and is unresponsive after that. I have to reset the arduino once or twice, then it stops doing that and prints normally. Once a print starts, I haven't had it stop in the middle yet, this only happens (so far) right when starting a print. There is no message on the LCD or in the log when this happens. I do have watchdog enabled, but I would think that would output some kind of message if that was what was doing it.

The second is that when the print is completed, the printer homes as instructed and then moves to Z=10 for some reason. My ending G-code is here:

M104 S0 ; turn off temperature G28; home X Y and Z axis M84 ; disable motors
The printer's dump area is defined as 0,0,400 (I have about 409mm in the Z axis) in repetier host.
I did see a message go by in the log that said something like "resending G1 Z10"... it said more than that, but I didn't copy it down. I'll grab it after the next print.

Repetier

Check host if you use it if there is a go to parking position activated with Z10 might be the problem also it should never go down but G28 at the end may confuse it especially if host things G28 does a zmin homing. Then it would add 10 to 0 from G28.

What bothers me more is the wait problem did not write any wait. I guess wait is a bad choice since the host filters waits away. Better call it wtemp so we see output. And please also post modified code fucntion completely. Lines are misleading since inserting lines changes them/ I change lines, so they are probably not where I expect.

Homing issue is strange. WHat is your z homing speed? Maybe increase it. Someone told me firmware crashes on very low speeds, but could not verify yet.