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()
I expected that temps['bed']['target'] will have a value of _70_ immediately after calling self._printer.set_temperature()
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.
1.2.16 (master branch) on rPi 2 with octopi
Marlin 1.0.2 Printer and Virtual Printer (Virtual Printer also on fresh VM installation of 1.2.16 master)
https://gist.github.com/derpicknicker1/bb488bead50a15ee2cb04d673c8e824f
I have read the FAQ.
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
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
M105response 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
maintenanceanddeveland will be part of any of the following releases and release candidates.