Time out after G4

[gmccauley]

What were you doing?

The MP Select Mini will turn the fan on while the hotend is above a certain temperature without turning it back off it seems. I've heard of folks putting a G4 (dwell) command at the end of their prints to allow the hotend to cool and then turning the fan off. Just like Issue #1506, the MP Select Mini is returning an ok immediately and then dwelling causing communication timeouts, then disconnects.

What did you expect to happen and what happened instead?

What I expected: OctoPrint to pause and wait the 4 minutes before attempting to turn off the fan.
What happened: Printer returned an ok after G4 and OctoPrint tried to turn the fan off while the printer was dwelling

Branch & Commit or Version of OctoPrint

OctoPrint 1.3.2 (master branch

Operating System running OctoPrint

OctoPi

Printer model & used firmware incl. version

MP Select Mini
Send: N1 M115*39
Recv: NAME: Malyan\x09VER: 2.9\x09MODEL: M200\x09HW: HA02

Browser and Version of Browser, Operating System running Browser

Google Chrome
Version 58.0.3029.110 (64-bit)

Link to contents of terminal tab or serial.log

Send: N53045 M8424
Recv: ok N53044 P14 B15 T:179.0 /0.0 B:59.6 /0.0 T0:179.0 /0.0 @:0 B@:0
Send: N53046 G4 P24000095
Recv: ok N53046 P15 B14
Send: N53047 M106 S098
Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N53048 M10545
Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N53049 M10544
Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N53050 M10536
Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N53051 M10537
Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N53052 M10538
No response from printer after 6 consecutive communication timeouts, considering it dead. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Changing monitoring state from 'Printing' to 'Offline: Too many consecutive timeouts, printer still connected and alive?'
Connection closed, closing down monitor

I have read the FAQ.

[foosel]

That Malyan firmware is driving me crazy. Claims to be "fully Marlin compatible", behaves like a Marlin's cousin twice removed and a drunk Repetier Firmware instead.

Try disabling automatic firmware detection under Settings > Features, then enable these options:

• Always assume SD card is present
• Actively pause communication during G4 dwell command
• Send a checksum with the command -> select "Always"

Screenshot:

That should fix it. If so please report back. I'll then make this checkbox part of the Malyan autodetection.

[gmccauley]

Your comments made me giggle this morning which was much needed. Thank You for that!

I'll try and test this tonight, but I found what I think is a little more elegant way to handle what I consider a bug in the printer firmware (turning the fan on and then never turning it off).

In my ending script, I'm now sending an M109 R45 to set the extruder temp to 45 degrees and wait (which acts as OctoPrint expects), then I turn the fan and extruder off. The only downside I can see is that since the printer only responds with the extruder temp during the wait, OctoPrint doesn't get updated temps for the bed, so it still displays the last temp it knew about. Once the wait is over, the temp is displayed accurately. I imagine the G4 command would act the same except for both the bed and extruder temp.

[foosel]

Mission accomplished, made people giggle, good day :)

Actually, the whole "keeping the fan on after a print to prevent heat creep in the hotend" should actually rather be handled in firmware if it's necessary for hardware reasons. It's a bit sad that the recommended method for these kinds of printers appears to be to completely bypass the firmware here and instead force users to effectively block their printer until that cool down procedure is accomplished. A firmware-side fix would be fairly easy to accomplish here (don't switch off fan when temperature is above n degC and the target is below that, if "fan off" command is encountered on serial acknowledge it but don't execute it until cooling has been achieved/ignore it altogether).

Your M109 R45 approach at least has the advantage that you'll get temperature updates of the extruder while it's cooling - with G4 the printer simply gives you the silent treatment and only returns to speaking terms when the dwell duration is over. I'd rather have my printer still talk to me but only report its hotend temperature than it not talking at all anymore ;)

[gmccauley]

I agree on all points, but hey, it was a $200 printer, what can I expect. :-)

I still test the above if you like later tonight when I get home from work.

[foosel]

Would be great, because if that setting solves at least the "oh noes, timeout!" from showing up (it really should), I'll add that to the detection for 1.3.4.

[gmccauley]

Well, it kinda worked? It waited for 4 minutes after the G4 before it displayed the ok and then executed M106 and received an ok and then changed the state to operational. It never displays that it tried to execute any M105's to get temperature though and then after about 2 more minutes, it says that there were communication timeouts.

When I checked on the printer, the fan was still running, but since it never issued an M105 after the dwell, I'm not even sure that the hotend was below the required temperature, so it's possible that OctoPrint turned the fan off and then the firmware turned it back on.

Terminal Output:
Send: N6233 M8443
Recv: ok N6233 P15 B15
Send: N6234 G4 P240000104
Recv: ok N6234 P15 B15
Send: N6235 M106 S0*85
Recv: ok N6235 P15 B15
Changing monitoring state from 'Printing' to 'Operational'
No response from printer after 3 consecutive communication timeouts, considering it dead. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Changing monitoring state from 'Operational' to 'Offline: Too many consecutive timeouts, printer still connected and alive?'
Connection closed, closing down monitor

[gmccauley]

Just for S&G, I rebooted the Pi after making those changes, and now it is working as expected (well, when I went to check it the fan was still running, and after looking at the first temp reading, the hotend was still at 72.5 so 4 minutes wasn't long enough to cool). I'll stick with the M109 to cool the hotend. Glad I could help confirm for you though.

Terminal Output:
Send: N6232 M8442
Recv: ok N6232 P15 B15
Send: N6233 G4 P240000111
Recv: ok N6233 P15 B15
Send: N6234 M106 S084
Recv: ok N6234 P15 B15
Changing monitoring state from 'Printing' to 'Operational'
Send: N6235 M10521
Recv: ok N6235 P15 B15 T:72.5 /0.0 B:41.5 /0.0 T0:72.5 /0.0 @:0 B@:0

[foosel]

Oops, forgot to comment, only mentioned in the above commit: The "block while dwelling" feature flag is now also automatically applied when a Malyan printer is detected.

Already on maintenance and devel, will be released with 1.3.5.

[foosel]

1.3.5 was released yesterday.