Here it is all over the place. You can see the B:55 /55 is correct then you get to T0:100 /55 which appears to be showing the /55 bed temp and then T1:110 /100 which is showing /100 the T0 temperature. Then if you look at the original T:110 /110 that appears to be showing the T1 set and temperature.
So the problem is I could right a plugin to sort out those fields but they change. Yea I am not kidding. They move around so let me show you another example from the exact same Qidi X-Pro
So here it is the same commands as before but now look.
T:100 /100 T0:100 and the final /100 are all representing T0 and no SET temp representing T1 is shown at all.
Octoprint showing the temperatures shows T0 as Bed, T1 as T0 and Bed as Bed for set temperatures.
I have no idea how Qidi displays the correct temperature on the display unless it uses the sensors right from the hardware on the motherboard and no GCODE which is my guess.
Soooo...
Has anyone solved this issue as of yet? I have 2 Qidi X-Plus printers and those work perfect with the plugin that solves some of the other issues. With those printers I can print as normal and it just works.
So for the hardware that has the issue it is the Qidi X-Pro
M115 - CBD make it.Date:Jan 23 2019 Time:14:58:22
Same M115 for both Q-Plus printers but single extruder does not have the temperature issues the X-Pro does.
Broken AF firmware. That ain't the only issue with it. First of all install the Fix CBD plugin from the repository. And then I'll need a full serial.log to try to make sense of this new derivative which apparently now even breaks temperature reporting.
Whoever CBD is, at this point I'd like to punch them. This firmware has caused SO much grief and support overhead now, it's not even funny anymore.
No matter what we do we won't be able to fix temperature reporting with the standard M105 command. What we will have to do is write some sort of a plugin that rewrites the M105 command to M4000 command which on the Qidi is a printer status command that returns the following...
But from this we can extrapolate the information we need.
B:23/0 (Bed)
E1:36/0 (Tool 0)
E2:1077/0 (Tool 1)
So to add insult to injury on a single extruder machine they still report E2:1077/0
I am capable of writing a plugin for this Qidi specific firmware and I can read through the source to figure this out or if someone wants to present an example of how I can make this work I would appreciate it.
Need to rewrite requests of M105 to M4000 then need to parse that string to get the temperatures from that and discard the rest of the useless data.
So basically what Qidi is doing is giving standards the finger and simply writing their own M codes to use for their printers which is just beyond lame.
Sophia (Qidi Support Email) said that the software engineer "promises" to fix M105 in the next firmware update.
So can a plugin accomplish this task in the mean time?
I don't mind writing a plugin but it is going to go beyond what your plugin is doing. On top of parsing the data correctly I need to be able to send M4000 out to the printer in place of M105 which is going to require what I really am not sure yet. I have not got in to the source or even read up if there is plugin documentation but that is my next step if someone else does not have a better solution.
Okay so I can send M4000 properly. I can receive and parse that line in to the proper temperatures but is there a hook to feed those temperatures to octoprint?
So I can create a parsed_temperature array but how can I feed that back to octoprint and have it be used properly?
I can not simply use the octoprint.comm.protocol.temperatures.received hook as it is never processes because it never receives the temperatures the way it expects to receive them. When I use that hook that trigger never gets fired.
Or can I modify the way octoprint parses the temperatures to start with? Then I could simply do that and it should just work.
So you are saying that the M105 commands are being sent to the printer, it is returning what looks like a temperature report, but OctoPrint fails to parse it at all so it never triggers the temperatures.received hook?
If that's so, we are definitely at @foosel's mercy
I don't think you understood my "kludge". Instead of substituting "M4000" for "M105", substitute "M4000,M105" for "M105", i.e. add an M4000 before the M105 and send both. I'm pretty sure the documentation has an example on how to do that. The M4000 will return the data you need and the M105 will trigger the hook where you will substitute good data for bad.
If you did understand me, then I'm not sure I understand your responses
Here is the plugin that could be severely cleaned up and optimized I am sure. But it is fully functioning at least on my Qidi X-Pro. This plugin does require you to have the "CBD Firmware Plugin" also installed from the Octoprint Plugin Manager.
Just to clarify what this does. On the X-Pro printer the original Qidi Firmware is severely broken. So temperatures are not reported properly and prevents you from using Octoprint at least for me. Your mileage may vary but it works perfect for me.
Basically it is using a different GCODE that Qidi invented for themselves that does report the temperature properly and formats the output so that Octoprint receives the proper temperature for both extruders and the bed. This allows Octoprint to function properly.
This plugin also detects if you have two extruders and if you do not and only have one it does nothing which is preferred. So if you install this on a different Qidi or even a single extruder printer that is not a Qidi it will not do anything but simply return the original output.
# coding=utf-8
import octoprint.plugin
import re
class QidiDualExtruderTempFixPlugin(octoprint.plugin.OctoPrintPlugin):
parse_m4000 = re.compile('B:(\d+)\/(\d+) E1:(\d+)\/(\d+) E2:(\d+)\/(\d+)')
# Credit to b-morgan for this rewrite routine I borrowed and modified for this purpose
def rewrite_m105(self, comm_instance, phase, cmd, cmd_type, gcode, *args, **kwargs):
if self._printer_profile_manager.get_current_or_default()["extruder"]["count"] > 1 and gcode and gcode == "M105":
return "M4000"
return cmd
def check_for_m4000(self, comm_instance, line, *args, **kargs):
# Check to see if we received the M4000 response and if so extract temperature for octoprint
if "B:" not in line:
return line
self._logger.debug("Original M4000 line %s" % line)
m = self.parse_m4000.search(line)
if self._printer_profile_manager.get_current_or_default()["extruder"]["count"] > 1:
new_line = ("ok T:%s /%s B:%s /%s T0:%s /%s T1:%s %s" % (m.group(3), m.group(4), m.group(1), m.group(2), m.group(3), m.group(4), m.group(5), m.group(6)))
else:
new_line = ("ok T:%s /%s B:%s /%s" % (m.group(3), m.group(4), m.group(1), m.group(2)))
self._logger.debug("Modified M4000 line %s" % new_line)
return new_line
__plugin_name__ = "Qidi Dual Extruder Temperature Fix"
__plugin_description__ = "This plugin changes the way Octoprint queries the temperature on Qidi dual extruder printers this is due to Qidi using a very broken firmware you will also need the Fix CBD Firmware Plugin"
__plugin_author__ = "Robert Mann"
__plugin_license__ = "AGPLv3"
__plugin_pythoncompat__ = ">=2.7,<4"
def __plugin_load__():
global __plugin_implementation__
__plugin_implementation__ = QidiDualExtruderTempFixPlugin()
global __plugin_hooks__
__plugin_hooks__ = {
"octoprint.comm.protocol.gcode.queuing": __plugin_implementation__.rewrite_m105,
"octoprint.comm.protocol.gcode.received": __plugin_implementation__.check_for_m4000
}
Convert the response into a proper response to m105. OctoPrint will parse that, no need to parse temperatures manually and feeding them back or anything, just rewrite the return.
Or, you know, flash a proper firmware that isn't going above and beyond to screw you over with interoperability issues with established industry standards.
Is there such a firmware that will work on these. That is the question.
Still have a little weirdness going on during the wait commands. But all in all it works now at least.
When I get the M4000 results that is exactly what I am doing. Simply rewriting them to what the M105 SHOULD look like and Octoprint is happy to accept that and it just works.
