I'm not sure if I'm misunderstanding this but I assumed that the 'Suppress temperature messages' tick-box would do what it says on the tin, but it doesn't seem to make a difference as the temperature messages just keep coming.
I am using Octoprint 1.4.0 on a Pi4 Model B Rev 1.1 running the OctoPi 0.17.0 image connected to a Creality CR-10s Pro running the Creality firmware 1.70.1
Is this a known issue? I can't find any reference to it in searches so I assume not.
Thanks for any help.
Chris
Please enable your serial.log and post it here. The "Suppress temperature messages" works with a standard Marlin temperature report, but unless you show us what your temperature reports look like, we can only guess.
This is what appears in the terminal -
Recv: == T:25.45 /0.00 == B:26.36 /0.00 @:0 B@:0
Recv: == T:25.45 /0.00 == B:26.36 /0.00 @:0 B@:0
Recv: == T:25.45 /0.00 == B:26.36 /0.00 @:0 B@:0
Recv: == T:25.45 /0.00 == B:26.36 /0.00 @:0 B@:0
Recv: == T:25.45 /0.00 == B:26.36 /0.00 @:0 B@:0
Recv: == T:25.45 /0.00 == B:26.36 /0.00 @:0 B@:0
Recv: == T:25.45 /0.00 == B:26.36 /0.00 @:0 B@
I have turned on serial logging, Is there a way to attach the log file or do I post it in here?
Here is what a "good" temperature report should look like:
Recv: T:21.97 /0.00 B:22.28 /0.00 @:0 B@:0
Recv: T:22.00 /0.00 B:22.07 /0.00 @:0 B@:0
Recv: T:21.97 /0.00 B:22.17 /0.00 @:0 B@:0
Recv: T:21.97 /0.00 B:22.10 /0.00 @:0 B@:0
It looks like yours are "embellished" with a few ==
Yes, that attached your octoprint.log. Next time you can attach your serial.log as well. 
This assumes that you have figured out how to SSH into your RPi using PuTTY (on Windows), ssh (on Linux), or something else on macOS.
Note that this is totally untested as I don't have a Creality CR-10s Pro running the Creality firmware 1.70.1. It also assumes that only the temperature report has the extra == characters. If that assumption is false, then I would use a regular expression that matched only the temperature report line.
Connect to octopi via SSH (or login as the effective octoprint user on your machine) copy this snippet and paste it straight into the terminal:
cat > /home/pi/.octoprint/plugins/Fix_Temp_Report.py << EOF
# coding=utf-8
from __future__ import absolute_import
def fix_Temp_Report(comm, line, *args, **kwargs):
while "==" in line:
line = line.replace("==","")
return line
__plugin_name__ = "Fix Temp Report"
__plugin_version__ = "1.0.0"
__plugin_description__ = "Remove extraneous == from temperature report"
__plugin_hooks__ = {
"octoprint.comm.protocol.gcode.received": fix_Temp_Report
}
EOF
sudo service octoprint restart
Brad,
I have a print running at the moment but I will give this a try when finished.
Chris
Hi Brad
just tested the fix and it didn't work. It would appear that the plug-in is not being run, or is not doing what it should. To try to debug the code I replaced the line = line.replace("==","") with line = line.replace("==","*****") but the messages still came out with the == in.
Checking in the directory the Fix_Temp_Report.py is now joined by Fix_Temp_Report.pyc and the plug-in is displayed in the Plugin Manager and is enabled.
Is there anything that I could have done wrong? Is there any way to debug the plugin to see if it is getting called ok? Would it be possible to add a print statement to display line before and after the replace?
Regards,
Chris
Brad
I modified the method as below -
def fix_Temp_Report(comm, line, *args, **kwargs):
while "==" in line:
line = line.replace("==","")
f = open("/home/pi/test.txt", "a")
f.write( line )
f.close()
return line
and the result in the file was -
T:24.45 /0.00 **** B:27.73 /0.00 @:0 B@:0
T:25.23 /0.00 **** B:28.27 /0.00 @:0 B@:0
so the replace is working and line is being parsed correctly. Looks as if the return should be correct but something is squiffy.
Regards,
Chris
If all you added is the open, write, and close then the **** in the output is disturbing. If the serial.log still contains the lines with the == in them, then I suspect that the problem is the wrong hook function or the hook function used is too late in the process. This is the documentation of the hook being used and a quick look at all the hooks didn't find anything more appropriate. Note that the documentation does contain a warning:
Make sure to not perform any computationally expensive or otherwise long running actions within these handlers as you will effectively block the receive loop, causing the communication with the printer to stall.
This includes I/O of any kind.
At this point, we may have to ask @foosel for some guidance. Is this the right approach? What is an appropriate method for debugging? I'm guessing using the logger or logging.
I have changed the suppress Terminal Filter to - (Send: (N\d+\s+)?M105)|(Recv: == T:.*$)
which seems to be doing the job. The problem with the plug-in code is strange in that it seems that the code gets the correct line data and returns the correctly amended data but somehow it is not being used.
Brad
further to my last message I have noticed that if you use a terminal filter you get [...] displayed to indicate the suppressed messages. If however you deselect the Suppress Temperature Messages all of the suppressed messages are then displayed. This indicates to me that the messages are being buffered somewhere.. Could this eventually present a problem with a large number of buffered lines?
@ChrisMower, I'm glad you found a way to suppress the messages. Obviously, OctoPrint's Terminal Filters are being run before the plugin hook sees the line. I originally authored this plugin to solve another Creality firmware transgression and it worked there so I thought I'd give it a shot here.
Your question about the buffered lines is beyond my pay grade. @foosel or someone more familiar with the OctoPrint internals would have to answer that one.
OctoPrint has a Discord server (icon at the top of this page) and you could try asking there in support-octoprint or dev-core.