2011年11月22日下午4点57分，jgeerds写道：

：我认为”未知：t：xxx.xx “错误消息具有误导性，应为：正在等待xxx. xx，当前温度xxx. xx
“未知：”由repg添加。我们可以重复，但是普林特伦
会很困惑。
是的，我也认为冷却应该是非阻塞的。如果
不总是这样，至少在很多情况下是这样。

40或以下的T是否可以接受为0？我们不一定需要完全冷却，只是“没有火灾危险”的温度。不太可能在超过40摄氏度的温度下操作，所以这将满足大多数人的期望。

主要问题是在M109命令期间，板变得完全无响应，不复位，不停止。唯一的出路是退出repG并拔掉UM，所以我会认为这是马林1. 0. 0 b1中的bug …

冷却行为现在可以在编译时配置：在配置中。h：
#定义冷却不等待为真
你能不能测试一下，如果这能解决你的问题，就关闭它。

基于GCODE的加热时阻塞的消除是不容易的，您需要在等待加热时解释新的GCODE，这是在同一个“线程”中完成的。
非常好的问候，再次感谢。

阻塞一切的m109似乎被解决了。谢谢你修理

与此相关，当前马林（3814 bbb）可以/应该具有更宽容的M109行为：现在，repg等待最多一分钟的温度达到设定点，尽管事实上，它是预热到正是该温度（但重置，因为一个孤独的M109在开始的gcode）。这将是伟大的，如果打印将开始，如果M109温度至少在+-1度。此时感觉就像在等待温度在+-0. 2度以内。

只需减少配置中的驻留时间。h：
#定义温度停留时间30 //（秒）
#define TEMP_HYSTERESIS 3 //（C°）+/-温度范围被视为“接近”目标温度

我尝试了15sec和4 deg，但UM仍然等待两次温度达到（尽管事实上它已经在范围内）

此外，cooldownnowait true在当前构建中不起作用（它在早些时候起作用）。

你好，
我不知道这对你是否有用，
但我打印了rapg 0026，并将最后Netfabb的GCode从M109 S0.000更改为M104 S0.000。
这对我来说很好。
M104接缝与M109相同，无需等待温度。

亲爱的背景，是的，改变M109到M104肯定是一个临时的补丁/变通办法，但从长远来看，代码应该与所有/大多数机器和gcode。

好的。是的。
我不是一个极客，但它是一个需要在GCode结束“等待”安装？

嗯，M109的固有功能是“等待温度”，这是一个重要的命令来预热机器，或者冷却到一定的温度。而且由于所有这些都是使命关键型的，所以M109 S0是一个例外，需要在固件中覆盖，以防止阻塞打印结束。以前的版本运行良好，只是2011年12月的版本重新引入了这个小错误。

好吧，
我知道这对我来说是一个很大的学习空间。
谢谢你的回答。

我想已经解决了…

此问题已自动锁定，因为在关闭后没有任何近期活动。请为相关错误打开一个新问题。