M109 S0 problem (with netfabb)

[jgeerds-zz]

netfabb turns off the heater at the end with M109 S0.0000.
Which means the print never officially finishes, because Marlin reports the "unknown t:xxx.xxx" back (until it would reach 0, which never happens). Reset and stop don't work.

PS: I think the "unknown: t:xxx.xx" error message is misleading and should read: "waiting for xxx.xx, current temp xxx.xx"

[bkubicek]

On 11/22/2011 4:57 PM, jgeerds wrote:

: I think the "unknown: t:xxx.xx" error message is misleading and should read: "waiting for xxx.xx, current temp xxx.xx"
The "unknown:" is added by repg. We could echo it, but then printrun
would be confused.
Yes, also I am of the opinion that cooldown should be non-blocking. If
not always, at least in many cases.

[armyofevilrobots]

Perhaps a T of 40 or under could be accepted as 0? We don't necessarily need to get to fully cool, just "no fire hazard" temperature. Unlikely the reprap is going to be operating in a temperature of over 40C, so that would meet most people's expectations.

[jgeerds-zz]

The main problem is that during the M109 command, the board becomes completely unresponsive, no reset, no stop. the only way to get out is quitting repG and unplugging the UM, so I would consider this a bug in Marlin 1.0.0b1...

[bkubicek]

The cooldown behaviour is now configureable at compiletime: in Configuration.h:
#define CooldownNoWait true
can you please test, if it this solves your issue, close it.

There is no easy fix for the removal of the blocking at heating based on gcodes, you would need to interpret new gcodes while waiting for the heatup, and this is done in the same "thread".
very nice greetings, and thanks again.

[jgeerds-zz]

the m109 blocking everything seems to be resolved. thank you for your fix

[jgeerds-zz]

Related to this, the current marlin (3814bbb) could/should have a more tolerant M109 behavior: Right now repg waits up to a minute for the temp to reach the set point, despite the fact that it is preheated to exactly that temp (but reset because of a lonely M109 at the beginning of the gcode). it would be great if the print would start if the M109 temp is at least within +-1 deg... it feels like it waiting for the temp to be within +-0.2 deg at the moment.

[bkubicek]

just decrease the residency time in configuration.h:
#define TEMP_RESIDENCY_TIME 30 // (seconds)
#define TEMP_HYSTERESIS 3 // (C°) range of +/- temperatures considered "close" to the target one

[jgeerds-zz]

I tried 15sec and 4 deg, but the UM still waits twice for the temp to reach (despite the fact that it is already within range)

[jgeerds-zz]

also, the cooldownnowait true doesn't work in the current build (it was working earlier).

[Backgrounder]

Hi,
i don´t know if it usefull for you,
but i print with rapg 0026 and i change the GCode from Netfabb on the end from M109 S0.000 to M104 S0.000.
Thats works fine by me.
The M104 seams like the same as M109 without the waiting of the Temp.

[jgeerds-zz]

Dear Backgrounder, yes, changing the M109 to M104 is definitely a temporary patch/work-around, but in the long run the code should work with all/most machines and gcodes.

[Backgrounder]

O.k. thats right.
I am not a geek, but is it a need in the end of GCode a "wait of" to install?

[jgeerds-zz]

Well, the inherent function of M109 is "wait for temp", it is an important command to warm up the machine, or cool it down to a certain temp. and since all that is mission critical, the M109 S0 is an exception that needs to be covered in the firmware to prevent blocking the end of the print. previous releases were working fine, it's just the Dec 2011 version re-introduced this little bug.