Delay on populate new bed target temperature #1543
Comments
When setting the tracked target temperature from a sent temperature command, the changes in tracked temperature were not propagated from the comm layer to registered callbacks. But since the standard printer also didn't make a copy of the mutable dict of tool temperatures, those were in fact updated even without propagation in the printer implementation when the values in the comm layer got updated, whereas the bed temperature - an immutable tupel - was not. Two wrongs sometimes do in fact make a right. In this case that led to target temperature changes on the tools immediately reflecting in printer.get_current_temperatures after the command was sent, but changes to the bed target taking until the next M105 response to propagate. Decoupling the data structures and adding propagation commands to the comm layer solves this issue. Fixes #1543
|
That was a prime example of two wrongs sometimes actually making a right. As things were, when sending a temperature command to the printer and updating the tracked target internally, those changes were actually not forwarded to the printer instance until the next This has now been fixed by a) making a copy of the data handed over from the client instead of just using it as is in the printer and b) triggering a temperature propagation after adjusting target values from sent commands. I've tested this using this minimal plugin based on your provided example. Note that the target temperature still will not updated immediately but only once the update command has been sent to the printer. Fix is merged on both |
|
1.2.18rc1 is out |
What were you doing?
I'm working on a plugin, where i set the bed temperature by calling
self._printer.set_temperature('bed',70)Immediately after that i grab the temperatures like this:
temps = self._printer.get_current_temperatures()What did you expect to happen?
I expected that
temps['bed']['target']will have a value of 70 immediately after callingself._printer.set_temperature()What happened instead?
self._printer.get_current_temperatures()will return the old value (value before set to 70) of['bed]['target']for about 2.5 seconds. After this time, the new value will be returned right.Temperatures of the tools will have the correct target temperature immediately after setting them.
Branch & Commit or Version of OctoPrint
1.2.16 (master branch) on rPi 2 with octopi
Printer model & used firmware incl. version
Marlin 1.0.2 Printer and Virtual Printer (Virtual Printer also on fresh VM installation of 1.2.16 master)
Link to octoprint.log
https://gist.github.com/derpicknicker1/bb488bead50a15ee2cb04d673c8e824f
I have read the FAQ.
The text was updated successfully, but these errors were encountered: