Octoprint: Delay on populate new bed target temperature

Created on 11 Oct 2016  路  2Comments  路  Source: OctoPrint/OctoPrint

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 calling self._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.

bug done

Most helpful comment

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 M105 response was parsed. The fact that the tool target temperature changes were reflected anyhow was caused by not properly isolating the data handed over from the communication layer - tool temperatures are in a (mutable) dictionary, one (actual, target) tuple per tool indexed by tool identifier, bed temperature is an (immutable) tuple. Updating the tool temperatures from the comm layer also updated the reference in the printer instance.

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 maintenance and devel and will be part of any of the following releases and release candidates.

All 2 comments

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 M105 response was parsed. The fact that the tool target temperature changes were reflected anyhow was caused by not properly isolating the data handed over from the communication layer - tool temperatures are in a (mutable) dictionary, one (actual, target) tuple per tool indexed by tool identifier, bed temperature is an (immutable) tuple. Updating the tool temperatures from the comm layer also updated the reference in the printer instance.

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 maintenance and devel and will be part of any of the following releases and release candidates.

1.2.18rc1 is out

Was this page helpful?
0 / 5 - 0 ratings