search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.04k stars 19.15k forks source link

Marlin Crashed after OctoPrint glitch #2781

Closed Grogyan closed 8 years ago

Grogyan commented 8 years ago

This is a weird bug, and I have encountered it only twice before. Marlin RC2 RAMPS MAX6675 thermocouple

OctoPrint 1.2.7 RPI2

http://pastebin.com/QMRbjHnh

OctoPrint on the RPI2 had been running for about 2 weeks, 24/7.

OctoPrint shuts down power to the 3D printer via M81 Likewise, extruder is also turned off along with the motors

After completing a print in the weekend, some 20 minutes later OctoPrint crashed, which in turn crashed Marlin. OctoPrint restarts OctoPrint reports Heater ID = 0 Extruder heats up beyond thermal limits

Fortunately I was able to pull the plug, otherwise there would have been a fire.

This is obviously a double bug, one in OctoPrint, and the other in Marlin. Regardless if there was a thermistor or not, the firmware corrupted the RAM somehow, this is my best guess.

AnHardt commented 8 years ago

Do you have any scripts defined in Octoprint? The most interesting one is "After connection to printer is established". If so, what is it looking like?

Grogyan commented 8 years ago

Referring from what Gina has stated here https://github.com/foosel/OctoPrint/issues/1118

I have go some logs to upload when I get tie at home to do so.

The only script that is run upon connection to OctoPrint is M81 to ensure the power supply is turned OFF before anything else. OctoPrint is also setup to automatically connect to the printer once it has booted.

KiteLab commented 8 years ago

If (we don't hope that) the error occurs again, please verify if the heater is really hot, or if OctoPrint only displays a hot heater. If a heater-error occurs, the heaters are shut down as good as we can, we send an error to stop the host, stop the communication, empty the command buffers, ..., and go into an endless loop to prevent a reboot. A reboot could execute a autostart file on the SD. After a reboot Marlin would be ready to receive new commands of potentially not stopped host. Stopping the communication means. OctoPrind will not get a new temperature reading and will display the state, when the communication stopped, for ever.

What i see in ritqyie could be a regulated heating at about 180° where OctoPrint doe's not know it happens, until about the half of the time. In the second half i see a dropping temperature (Power supply off? Open door? Starting fan? Reconnect shutting down the power supply?). Right after that, the target temperature is set to 180° but the heater needs to long to heat. The temperature rises to late or not enough. The protection mechanism steered by

  #define WATCH_TEMP_PERIOD 16                // Seconds
  #define WATCH_TEMP_INCREASE 4               // Degrees Celsius

detects an error, ... (see above) and stops the communication.

The remaining question is, how can it be, that there is an working and regulating heater, but OctoPrint does now know about the target temperature.I can imagine two different variants. Ether OctoPrint only tracks temperature commands sent by it selves. Than a sd-cadr-program or a change initiated by the display would not be noticed. Then Marlin can not improve it. Or OctoPrint tries to interpret Marlins answer to a M105 command (where the target information is in) and they misunderstand each other.

There is a PR around (#2768 #2822) what makes the Marlin output more similar to the Repetier output and can display the temperatures/targets/heater-states also during the long lasting/waiting g-codes (M109, M190, M303), helping to at least analyse two issues (#2673, #2763). As usual nobody cares about it. No positive or negative test results, no critic voices, no feedback, no interest, no merge.

lrpirlet commented 8 years ago

@KiteLab err hum... I think I do care... I care enough in fact to thank the author of this branch "Marlin-ConformingHostMessages" that I tested specifically to visualize the heating of the bed and the heating of the head in Repetier... In 2 words: it works... In 4 words: Thank you very much... Only I was waiting to print in various conditions (play with the heaters manually then start print, or print directly) before to report success... :+1:

Grogyan commented 8 years ago

@KiteLab After the discussion I had with Gina, OctoPrint only reads back M105 messages. It has some internal timers to automatically disconnect if for some reason communication is lost.

However I cannot say for sure that the problem isn't with OctoPrint, and I'm now leaning more towards there being a problem with Marlin, maybe something goes wrong with the ISR.

Yesterday I also had a hunch, which I have yet to follow up on, that there is a log problem from within the Raspberry PI, which somehow slows down communication drastically.

With regards to the screenshot, the extruder was turned on after a previous print had completed, or cancelled, and the heater was reheating back up to target temperature before the glitch occurred.

There seems to be a number of bugs/PRs relating to realtime reading of the heaters, so am not sure exactly which one to use to try out, and see if the problem still exists for me.

github-actions[bot] commented 2 years ago

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.