On the temperature tab there are a number of issues. Firstly after the initial preheat is reached, the charting doesn’t report the correct temperature. I only found this out whilst printing a temperature tower. I thought I first I hadn’t set the temps right in the slicer, because the actual temperature was changing on the octoprint screen. I checked my printer and sure enough the temps were changing. I could see the target temp changing in octoprint but not the actual temp.
What did you already try to solve it?
Rebooted Pi and printer but still problem persists.
Have you tried running in safe mode?
No
Did running in safe mode solve the problem?
No
Complete Logs
octoprint.log, serial.log or output on terminal tab at a minimum, browser error console if UI issue ... no logs, no support! Not log excerpts, complete logs.)
Hopefully these are attached, I’m working from a mobile device. octoprint.log (325.0 KB) serial.log (592 Bytes)
Additional information about your setup
OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible
Octopi 0.18.0 running in raspberry 3B freshly installed a few days ago. Connected to Ender 3 v2 running the Latest Marlin firmware with Bl Touch. Version 4.2.2 main board.
I enabled serial reporting - See attached. I built the Octopi following the Howchoo guide. Within this it included installing both Creality Temp Fix Plugins.. So I can confirm, both of those are installed.serial.log (1.2 MB)
According to that serial.log, you aren't printing, you are streaming a file to SD. During that, OctoPrint can't query for temperature (because otherwise the temperature query would be written to SD, not executed) and your firmware also doesn't auto report it, so no graph updates.
The binary garbage in your ok lines is concerning, the fact it happens on EVERY confirmation indicates a firmware bug however and not noise.
Creality Marlin or official Marlin? If Creality - flash official. Creality firmware is sadly known to have a lot of problems in their communication layer implementation.
Suboptimal tutorial then, you only ever need one and you need to look at your printer output to determine which one.
Firmware downloaded from this site - https://marlin.crc.id.au/ - As I understand it, nightly builds of the official Marlin Firmware. I am using Ender3-V2-BLTouch-20210130.bin
In terms of incorrect use of plugin, fair point, but as I'm brand new to this, I have to start somewhere right and at first look I wouldn't have know to even look at the terminal output, and I'm still not sure exactly what I'm looking for. Would it be best to remove/disable those plugin to begin with?
I should also add - I enabled the log at a point I enabled upload to SD and then subsequently started a print - There should be details captured in the serial log of the print itself.
If you are not using Creality firmware, you don't need those plugins.
However, something is still wonky with that firmware you installed, as I pointed out the ok lines contain binary garbage. Smells like a bug, which considering you installed a nightly build and as I just heard they are also currently messing around with the serial comms isn't completely unheard of. Don't try to run a nightly build until we are sure comms work in principle with your printer please, you are just dragging in more possible errors.
First of all, before we can do anything here, we need a full serial.log of the whole connection handshake and an actual print, not a "send file to SD" one but one that actually involves the printer moving and heating and extruding plastic. So, best flash a stable firmware build, then uninstall those plugins, restart in safe mode (because we also don't want third party plugins to interfere here), enable serial.log, connect to your printer (important - FIRST enable the log, then connect), print a job, check if it still has temperature issues, if so, upload the resulting serial.log here, otherwise the issues are caused by one of your third party plugins.
Apologies, you are right. the switch over hid itself well. There's still not a single M115 to be seen, so chances are your firmware reported it does temperature auto reporting. To confirm, we need the serial.log from the full connection handshake.
Edit: Your firmware indeed seems to claim it supports temperature autoreporting:
2021-01-31 11:30:27,624 - octoprint.util.comm - INFO - Printer reports firmware name "Marlin bugfix-2.0.x (Jan 30 2021"
2021-01-31 11:30:27,687 - octoprint.util.comm - INFO - Firmware states that it supports temperature autoreporting
But then it doesn't report anything. So that might also be a firmware bug. Try a stable firmware build.
Don't use Marlin nightly builds for now, give it a few more days. I have just learnt that they broke a lot of things in the serial comm, and have fixed most of them so far but only in the last day or so.
The closed issue queue tells a lot of the story, there's been a massive number of issues recently.
I have to reiterate again (because this is a recurring issue) that Marlin development nightlies are not meant for use in production. If something doesn't work in a development nightly it is likely not an OctoPrint issue. Always roll back to stable build, or an earlier nightly if something just broke.
I don't know how to be clearer, if you are having issues on a development build maybe that is the exact reason. In my mind, this is the absolute first thing to try when I see an issue that is not explained.
Sorry for the rant, but that's the second post today I have seen these random problems with people assuming that Marlin development builds are stable and production ready.
What you have to bear in mind is that from the site I am accessing my firmware (one that was recommended as the creality firmware has intentially had features disables), doesn't have the concept of a 'Stable Build' - If you refer to Creality own I refer back to the point I just made - If you refer to one of the 3rd Parties such as Smith3D, that was a nightly build at some point right? So as someone new to this field, how do I go about ascertaining what is a nightly build - Yes, you are right, it was a rant. I'm sure you feel you have justification, but please bear in mind, as I have already said, I'm new to this field. I have tried to do a lot of research, but fact is, I don't know what I don't know.
So, whilst I'm running new logs, how do I find out what is considered to be a Stable Build?
That's absolutely understandable and no one is claiming otherwise.
You ran into this problem at what could be considered the worst time really. I guess someone told you to fetch firmware builds from there without warning you about potentially unstable builds. Normally, Marlin nightlies are pretty stable, right now however there's a bit of an increased bug rate in what gets committed. And - sadly as usual - people are blaming what they see first when interacting with their printer for any problems, OctoPrint, and not whatever else might be at fault, and that is a bit frustrating, especially multiplied across months and years of project maintenance.
In general, especially if you are a beginner, keep your hands from anything that hasn't seen a stable release or at the very least a release candidate. To check on what is the latest stable release of Marlin, look here: Download | Marlin Firmware and then use the version information available on that page to go from there in making your flash decisions.
Oh I'm certainly not blaming Octoprint. It just seemed to logical place to turn to. I'm not in the position to be able to compile my own firmware at this point (I may look into this when I have more time). I'm struggling to understand the version number of the nightly firmware I'm downloading as it only states the date and 2.0.x bugfix. I further can't see a way to go back to a known good version of compiled firmware making use of the service i have from the site in Aus. It sounds like the issue is known and a fix will come about. I'm not sure how I can ascertain when that fix is made, so maybe the best option for me is to update to future releases as they come out. unfortunately that means that I may constantly be chasing nightly builds and suffering any potential new bugs as they come until I can get to a point of having a working firmware. As I say, at this point it's not causing a hole lot of problem for me, more an annoyance.
