ObjectModel for tool temp not updated properly
-
I think I've found a bug regarding updating the object model when canceling a print. I don't know if this is originating from DSF or DWC.
The ObjectModel for the heater is updated perfect fine when starting a print and of course setting the temperatures manually.
However, I have just found out, that if cancelling a print the UI shows 0° for both active and standby tool temperature, but the ObjectModel still says e.g 230°:[ { "active": 0, "avgPwm": 0.003, "current": 34, "max": 120, "min": -273.1, "model": { "coolingExp": 1.4, "coolingRate": 1.112, "deadTime": 2.3, "enabled": true, "fanCoolingRate": 0, "heatingRate": 0.402, "inverted": false, "maxPwm": 1, "pid": { "d": 1.219, "i": 0.1093, "overridden": false, "p": 0.74414, "used": true }, "standardVoltage": 0 }, "monitors": [ { "action": 0, "condition": "tooHigh", "limit": 120 }, { "action": null, "condition": "disabled", "limit": null }, { "action": null, "condition": "disabled", "limit": null } ], "sensor": 0, "standby": 0, "state": "off" }, { "active": 230, "avgPwm": 0.003, "current": 98.29, "max": 300, "min": -273.1, "model": { "coolingExp": 1.4, "coolingRate": 0.693, "deadTime": 2.2, "enabled": true, "fanCoolingRate": 0.784, "heatingRate": 4.248, "inverted": false, "maxPwm": 1, "pid": { "d": 0.115, "i": 0.0107, "overridden": false, "p": 0.07456, "used": true }, "standardVoltage": 24 }, "monitors": [ { "action": 0, "condition": "tooHigh", "limit": 300 }, { "action": null, "condition": "disabled", "limit": null }, { "action": null, "condition": "disabled", "limit": null } ], "sensor": 1, "standby": 230, "state": "off" } ]I first thought it is a bug in my Home Assistant integration, but the issue seems with the API (tested only SBC) or DWC.
-
@Lyr3x which firmware version?
-
@jay_s_uk
3.4.5 on a Duet MB6HCIf I manually edit the active temperature to 0° it is of course updated. Can check tomorrow, but I think when a print finishes successful the temperature is also set to 0°
-
@Lyr3x do you have a cancel.g file and/or a stop.g file in /sys, or not?
-
@Lyr3x Sounds odd to me. You can verify if it is a communication bug of DSF/DWC by running
M409 K"tools" F"d99vn"and comparing the values, because that queries the tools key directory from RRF. Note that M0 may turn off all heaters, that code is sometimes called at the end of prints and definitely to cancel a paused print. The final behaviour depends on whether cancel.g/stop.g is present and on the contents of those files if present. -
@Lyr3x I have checked the code. If you have neither stop.g nor cancel.g then RRF turns off all heaters when a print is cancelled, but it doesn't reset their temperatures to 0. If you do have cancel.g then the contents of that determine what happens; and it falls back to stop.g if there is no cancel.g. So I can't take this any further without knowing what (if anything) you have in those files.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 Sorry for the late reply. Was very busy in the last days.
I have a
stop.gin my /sys and here's the content. Actually never touched that.; ========================================================================================================= ; ; stop.g ; called when M0 (Stop) is run (e.g. when a print is cancelled) ; ; ========================================================================================================= ; G10 P0 S-274 R-274 ; turn off extruder M140 S0 R0 ; set bed temperature to 0C M140 S-274 ; set bed temperature to 0K to turn it off M107 ; turn off fan M150 u255 P255 G91 ; relative positioning M98 P"0:/sys/homex.g" M98 P"0:/sys/homey.g" ; ; ========================================================================================================= ;I didn't know about that behavior. Do I understand you correctly, that my
stop.gis missing, then something likeM568 P1 R0 S0?
But why is the API responding then a different state than the RRF ObjectModel in the first place? I thought that the ObjectModel is a real representation of the internal states from RRF and this model is used as a response for the API resources. As you can see below, the ObjectModel itself looks fine if querying with the GCode.Here is the result for the M409.
M409 K"tools" F"d99vn" { "key": "tools", "flags": "d99vn", "result": [ { "active": [ 0 ], "axes": [ [ 0 ], [ 1 ] ], "extruders": [ 0 ], "fans": [ 0 ], "feedForward": [ 0 ], "filamentExtruder": 0, "heaters": [ 1 ], "isRetracted": false, "mix": [ 1 ], "name": "Hemera", "number": 0, "offsets": [ 0, 5, 0 ], "offsetsProbed": 7, "retraction": { "extraRestart": 0, "length": 2, "speed": 16.7, "unretractSpeed": 16.7, "zHop": 0 }, "spindle": -1, "spindleRpm": 0, "standby": [ 0 ], "state": "active" } ], "next": 0 }When we now look at the response of the API, we get a different response:
curl -X GET http://192.168.2.116/machine/status | jq '.heat.heaters[1]' -> { "active": 220, "avgPwm": 0, "current": 31.7, "max": 300, "min": -273.1, "model": { "coolingExp": 1.4, "coolingRate": 0.693, "deadTime": 2.2, "enabled": true, "fanCoolingRate": 0.784, "heatingRate": 4.248, "inverted": false, "maxPwm": 1, "pid": { "d": 0.115, "i": 0.0107, "overridden": false, "p": 0.07456, "used": true }, "standardVoltage": 24 }, "monitors": [ { "action": 0, "condition": "tooHigh", "limit": 300 }, { "action": null, "condition": "disabled", "limit": null }, { "action": null, "condition": "disabled", "limit": null } ], "sensor": 1, "standby": 220, "state": "off" }Here, both active and standby temperatures are not reflecting the internal(?) status. As I rely on the API for the HASS integration, the values are off after canceling a print. Hope that helps and clarifies the situation!
-
@Lyr3x Your two queries don't match, using M409 you're quering the tools and using jq, you're selecting heat.heaters[1]. To get equivalent data, you should call
curl -X GET http://192.168.2.116/machine/status | jq '.tools'instead. -
@chrishamm Okay, that is confusing.
Why do we have two objects in place which provide the same information, but maybe they don't in reality?
Currently, I use the heaters to get the heating values for all tools and the bed and besides the described behavior this complies also with the UI values.
But in the end, reflectheat.heaters[1]the heater of the tool#1.Will check the
toolsobject later and report if the behavior is the same.[ { "active": [ 0 ], "axes": [ [ 0 ], [ 1 ] ], "extruders": [ 0 ], "fans": [ 0 ], "feedForward": [ 0 ], "filamentExtruder": 0, "heaters": [ 1 ], "isRetracted": false, "mix": [ 1 ], "name": "Hemera", "number": 0, "offsets": [ 0, 5, 0 ], "offsetsProbed": 7, "retraction": { "extraRestart": 0, "length": 2, "speed": 16.7, "unretractSpeed": 16.7, "zHop": 0 }, "spindle": -1, "spindleRpm": 0, "standby": [ 0 ], "state": "active" } ]Looking at the response, I (as expected) only get the reference to the heater number and not the heater values. So the values from
heat.heater[1]do not fit the GCode call, but the gcode also do not show the temperature values, right?
M409 K"heat"show the same IMHO wrongactiveandstandbyvalues.M409 K"heat" { "key": "heat", "flags": "", "result": { "bedHeaters": [ 0, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 ], "chamberHeaters": [ -1, -1, -1, -1 ], "coldExtrudeTemperature": 160, "coldRetractTemperature": 90, "heaters": [ { "active": 0, "avgPwm": 0, "current": 22.47, "max": 120, "min": -273.1, "model": { "coolingExp": 1.4, "coolingRate": 1.112, "deadTime": 2.3, "enabled": true, "fanCoolingRate": 0, "heatingRate": 0.402, "inverted": false, "maxPwm": 1, "pid": { "d": 1.219, "i": 0.0749, "overridden": false, "p": 0.74414, "used": true }, "standardVoltage": 0 }, "monitors": [ { "action": 0, "condition": "tooHigh", "limit": 120 }, { "condition": "disabled" }, { "condition": "disabled" } ], "sensor": 0, "standby": 0, "state": "off" }, { "active": 220, "avgPwm": 0, "current": 29.2, "max": 300, "min": -273.1, "model": { "coolingExp": 1.4, "coolingRate": 0.693, "deadTime": 2.2, "enabled": true, "fanCoolingRate": 0.784, "heatingRate": 4.248, "inverted": false, "maxPwm": 1, "pid": { "d": 0.115, "i": 0.0115, "overridden": false, "p": 0.07456, "used": true }, "standardVoltage": 24 }, "monitors": [ { "action": 0, "condition": "tooHigh", "limit": 300 }, { "condition": "disabled" }, { "condition": "disabled" } ], "sensor": 1, "standby": 220, "state": "off" } ] } }
Of course, I am rather new to the Duet and RRF API so please feel free to correct me if I am wrong! I just want to make sure that both the API is delivering correct and consistent values and that my integration is working fine
