Octoprint doesn't read M106 command

Coming from another post Ive seen on this board ( Part Cooling Fan, does not work while Printing ) this issue seems not to be resolved, at least not for me, nor for the OP of the other thread. Anycubic support does very little on this matter, and its not an electrical problem:

Problem
When printing something via octoprint (only when not printing a file on the printer's SD), nozzle fan doesnt start at all.
If i send an M106 or M106 S255 command via the Terminal Tab it doesnt do anything
If I send the command when printing is stopped, it works.
It seems that when not printing from the printer's SD somehow the M106 / M107 commands are ignored

What did you already try to solve it?
I put an M106 S255 command in the "Before Print Starts" section under GCODE Scripts in Octoprint, and it seems working, although it ovverides any fan speed changes in the GCODE file and the entire purpose of having the fan starting at a given layer.

I will not post a log of when printing via SD because the only comands passed are ok's and temperature warnings. Logs of when printing via internal memory are normal, except there are no M106 commands at all. Seems like they got stripped from the file. Obviously if I check the file in my pc all the commands are there where they need to be

OctoPrint 1.3.11 running on OctoPi 0.16.0 on a RPi 3b+, printer is Anycubic Chiron running stock firmware 1.3.0 (Marlin based)

Id really like to keep on printing via RPi's memory because when printing via SD the Gcode viewer doesnt work and also uploading a file on the SD via octoprint takes ages, but this fan problem is giving me headaches
Thanks to whoever will try to give some advice

So, if you go to the Terminal and enter M106 S255 or M107 neither command works? Does your firmware respond at all to these commands and if so, what does it say?

Thats correct. If I send the commands via terminal they are ignored, although in the terminal window the send and recv: ok lines do appear when I enter M106 S255. But they are executed only when idle or when printing from SD. I am printing in this moment, directly from SD, and I can see from the webcam that the fan is working

OctoPrint had nothing to do with these commands working or not. As long as it's sending them it's doing its job. If you send them from the terminal and nothing happens, that's your firmware being weird.

Just to rule out any kind of third party plugin interfering I'd suggest to run in safe mode and see what happens there.

I'd also like to add that I remember the stock Anycubic firmware being weird in general with regards to responses and commands. Maybe M106 and M107 aren't what they would be here.

1 Like

Hello, thanks for your reply. As I said, those commands only work when printing directly from SD (I just launched a file stored in the printer's SD from within Octoprint and the fan started as specified in the Gcode, after layer 3), (again, i'm not posting the Serial.log because the only commands passed when printing via SD are temperature and SD status reports). If I try to print a file from other sources (i.e. by uploading on to Raspberry Pi's memory), everything works fine, Gcode Viewer perfectly, except those 2 commands. Even the 2 FAN ON, FAN OFF buttons in the Control tab do nothing when pressed. They do work however when the printer is idle. Is this really a firmware problem?
If it would be such, I imagine it should never work.
Anyway after this print I will try to run Octoprint in safe mode and start again a print from Pi's internal memory, and I will post Serial.log which eventually will exhibit all commands

If you see them getting sent to the printer in the terminal tab, and they don't cause a change, then yes, this is a firmware problem. If they don't even go over the line, somethings off and my money would be on some plugin because there's definitely nothing filtering these commands in core OctoPrint.

I am now printing a 1-hour file uploaded onto the Pi's memory. Fan didnt start when reched layer 3. I paused job and manually pressed FAN ON button under Control tab, nothing. I manually entered M106 S255 into terminal, nothing. Although in the terminal it said "recv: ok" after inputting the command. So why when printing from SD everything works fine but not when printing from internal memory (and thus unlocking all features of Octoprint like gcode viewer)?

You need to ask your printer manufacturer why it's supposedly Marlin but yet it doesn't support the standard behavior of M106 and M107.

Already opened a ticket at Anycubic, their agent replied giving me a 18 hour vase stl file... nice support

serial.log (705.5 KB) Here's my serial.log running in Safe Mode and printing a file via usb. First couple of M106's and M107's in the log are me trying to send commands via terminal and FAN ON button on the Control Tab. Fan never started as seen on the camera image


I will try to change the power supply since sometimes it flashes the undervoltage icon.
An as a last resource I will try to install Repetier Server on another Pi I have, just to be sure if it is a firmware issue.

Another weird behavior, I changed the power supply to one capabe of giving 5.1V 3A to the Pi, and I ran a small gcode that simply starts and stops the fan a few times. Uploaded to Pi's memory and then started printing,the fan goes on and off as it should. Then printed the same file as my previous post and it doesnt work anymore. Could it be something interfering in the gcode generated from Cura?

1 Like

Do you maybe have some custom start gcode in cura?

As far as I know, I have no starting GCODE in Cura, but I do have an ending GCODE that clean the nozzle. Ill check again when I return home this evening

So it sounds like you had an undervoltage condition, you replaced the power adapter with something beefier, created a small gcode file and printed it in safe mode and the fan actually toggled on/off. And yet, the bigger file didn't toggle the fan.

This is slightly better. And yet, it never responds to commands in the Terminal? Assuming that you're sending the correct commands then it sounds like possibly a serial problem (I noticed a lot of garbage characters in your serial.log).

I noticed it too, they appear only when Octoprint connects to printer. Im gonna try change the usb cable too.Anyway today i tried other things and the behaviour is the same as always. No fan starts when feeding gcode from Cura and printing through USB, but it does start when i copy the same file directly onto the printer's SD

You are most likely using D9 port for the fan

Configuration_adv.h

#define E0_AUTO_FAN_PIN -1 // Protomaker Black Sprint Original using RAMPS Extruder to PNW the fan that blows onto the model i.e. PLA model cooling



1 Like

Note at the time of posting this The Deskboard Plugin does not show the Fan speed even if the fan is actually working

I'm guessing not, but did you get anywhere with this?

I see exactly the same behaviour here - if I copy gcode to the SD card and then print it, everything is fine; if I upload the same gcode file to the OctoPi and print it from the Pi's storage, the part cooling fan doesn't run.. very weird!

Read foosel's response above. Try the command in the OctoPrint terminal and look for a change in the fan. Try it also in Safe Mode if that didn't work. Ultimately, the firmware is definitely a part of all this but you need to see how the firmware responds to your attempts.

M106 S255 via Terminal turns the fan on, so does the button "Fan on"
When streaming a print, I see the command go over the wire - the fan starts and then the instant the head starts to move.. it stops again; there was no corresponding "Fan stop" command sent.

Very weird, and would seem to be a firmware issue - I haven't tried printing via Cura yet (which I imagine does what OctoPrint does - streams the Gcode over "serial"). If Cura works when sending the same Gcode, then the problem would have to be something specific to OctoPrint - if Cura behaves the same, then it's a firmware issue.. I know plenty of folks in the support groups print direct from Cura without issue, which rather implies OctoPrint be the culprit, as nonsensical as that seems, but I do need to test for myself to be sure.