Closed lrpirlet closed 9 years ago
Repaired this bad behavior by changing the M111 code from
inline void gcode_M111() {
marlin_debug_flags = code_seen('S') ? code_value_short() : DEBUG_INFO|DEBUG_COMMUNICATION;
SERIAL_ECHO_START;
if (marlin_debug_flags & DEBUG_ECHO) SERIAL_ECHOLNPGM(MSG_DEBUG_ECHO);
// FOR MOMENT NOT ACTIVE
//if (marlin_debug_flags & DEBUG_INFO) SERIAL_ECHOLNPGM(MSG_DEBUG_INFO);
//if (marlin_debug_flags & DEBUG_ERRORS) SERIAL_ECHOLNPGM(MSG_DEBUG_ERRORS);
if (marlin_debug_flags & DEBUG_DRYRUN) {
SERIAL_ECHOLNPGM(MSG_DEBUG_DRYRUN);
setTargetBed(0);
for (int8_t cur_hotend = 0; cur_hotend < EXTRUDERS; ++cur_hotend) {
setTargetHotend(0, cur_hotend);
}
}
}
to
inline void gcode_M111() {
marlin_debug_flags = code_seen('S') ? code_value_short() : DEBUG_INFO|DEBUG_COMMUNICATION;
SERIAL_ECHO_START;
if (marlin_debug_flags & DEBUG_ECHO) SERIAL_ECHOLNPGM(MSG_DEBUG_ECHO);
// FOR MOMENT NOT ACTIVE
//if (marlin_debug_flags & DEBUG_INFO) SERIAL_ECHOLNPGM(MSG_DEBUG_INFO);
//if (marlin_debug_flags & DEBUG_ERRORS) SERIAL_ECHOLNPGM(MSG_DEBUG_ERRORS);
if (marlin_debug_flags & DEBUG_DRYRUN) {
SERIAL_ECHOLNPGM(MSG_DEBUG_DRYRUN);
setTargetBed(0);
for (int8_t cur_hotend = 0; cur_hotend < EXTRUDERS; ++cur_hotend) {
setTargetHotend(0, cur_hotend);
}
}
SERIAL_EOL; //added By lrp to avoid Hanging the M111
}
Sorry, no idea why it works , I just tried that to "close" the line so that the ack is not taken as an item to print... Someone knowing C++ should have a look...
Ok, #2394 includes this adjustment, which might just be a kludge, but we'll see. I'm not sure where the "echo:ok" is coming from. I can't find any "ok" with SERIAL_ECHO_START
in front of it, and I can't find any place where SERIAL_ECHO_START
is being called without something following it.
Actually, before we think about merging #2394, see if this also fixes the issue for you (somehow):
inline void gcode_M111() {
marlin_debug_flags = code_seen('S') ? code_value_short() : DEBUG_INFO|DEBUG_COMMUNICATION;
if (marlin_debug_flags & DEBUG_ECHO) {
SERIAL_ECHO_START;
SERIAL_ECHOLNPGM(MSG_DEBUG_ECHO);
}
// FOR MOMENT NOT ACTIVE
//if (marlin_debug_flags & DEBUG_INFO) SERIAL_ECHOLNPGM(MSG_DEBUG_INFO);
//if (marlin_debug_flags & DEBUG_ERRORS) SERIAL_ECHOLNPGM(MSG_DEBUG_ERRORS);
if (marlin_debug_flags & DEBUG_DRYRUN) {
SERIAL_ECHO_START;
SERIAL_ECHOLNPGM(MSG_DEBUG_DRYRUN);
disable_all_heaters();
}
}
@thinkyhead, many thanks, The code above, that made its way in the development, completely solve the issue... I do not know where this "ok" did come from, except maybe if the acknoledge was mistakenly used as an argument (?continuation?) to the SERIAL_ECHO_START command...
It was the SERIAL_ECHO_START
at the beginning. If the M111
command didn't set either DEBUG_ECHO
or DEBUG_DRYRUN
then it would only print echo:
with no newline, swallowing the next ok
.
Sounds like you might have this exact problem with M501 as well. Example problem as seen in OctoPrint.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
I downloaded the Development version yesterday 3-Jul in order to test the patch over the G29… I always use Repetier-Host V1.0.6 in “ping-pong” mode where the host software waits the acknowledge before issuing the next command… The downloaded one just fails. Repetier stops with
It looks like repetier is waiting for the ack… The GUI announce 2 commands pending… I waited about 2 minutes without any progress...
Note that it used to work with older version of the Marlin firmware…
a working one (development 2-6-2015)…