M116 & G92 E0 Hang Sanguinololu 1.3b about teacup_firmware HOT 11 CLOSED

To shorten this down to
M116
M92 E0

M92 isn't supported (whatever that is), probably you mean G92 E0, right?

When using this sequence Teacup waits until temp is achieved (something like a minute), then processing continues. Could be improved, though, as waiting for temp should be asynchronous.

from teacup_firmware.

BTW., do you get this "Temp achieved" message after a minute? If not, Teacup simply doesn't detect the temperature is achieved and thus won't proceed.

from teacup_firmware.

Yeah Sorry G92 E0, D'oh
And no 'temp achieved' messages.

Would that cause a blocking situation for all subsequent commands

from teacup_firmware.

Yes, not achieving temperature blocks further proceeding. That's the point of M116, after all.

from teacup_firmware.

gcode_process.c that case M116 is different to M109 Literally

enqueue(NULL);
break;

M109 still work right? is that a blocking cmd?

from teacup_firmware.

Yes, M109 blocks. M109 is also gone in the Gen7 branch already, as it's a bit pointless. Can be replaced with M104 & M116.

from teacup_firmware.

Well the Good news is I can workaround this by getting to temp manually then start print after i comment out M116/M109 type commands. G92 does not stop print, only after M116/M109

from teacup_firmware.

The code checking wether temperature is achieved is in temp.c, line 294...300. For debugging you can insert this in line 301:

sersendf_P(PSTR("Sensor %d: last_read: %d  residency: %d\n"),
           i,  temp_sensors_runtime[i].last_read_temp,
           temp_sensors_runtime[i].temp_residency);

This will output all the read temperature values. "residency" should count up to 6000 as soon as the temperature is reached and then stay there. In case residency is set back to 0 occasionally, your temperature readout is flakey. If you can imagine how to detect this or how to deal with this, I'm all ears.

Raising TEMP_HYSTERESIS in config.h should help dealing with this, too. It raises the allowance for instable temperature readings.

from teacup_firmware.

I can workaround this

Well, I if the failure is indeed due to a flakey sensor I'd rely on you and your hardware to find a fix :-)

from teacup_firmware.

Proposed fix/reliability enhancement: ce7ab40

from teacup_firmware.

Looks like this is resolved. If not, please open a new issue with a description of the behaviour of the code in the current experimental branch. Thanks for reporting!

from teacup_firmware.