Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    ObjectModel for tool temp not updated properly

    Scheduled Pinned Locked Moved
    Duet Web Control
    4
    9
    370
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Lyr3xundefined
      Lyr3x
      last edited by Lyr3x

      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.

      jay_s_ukundefined chrishammundefined 2 Replies Last reply Reply Quote 0
      • jay_s_ukundefined
        jay_s_uk @Lyr3x
        last edited by

        @Lyr3x which firmware version?

        Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

        Lyr3xundefined 1 Reply Last reply Reply Quote 0
        • Lyr3xundefined
          Lyr3x @jay_s_uk
          last edited by Lyr3x

          @jay_s_uk
          3.4.5 on a Duet MB6HC

          If 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°

          dc42undefined 2 Replies Last reply Reply Quote 1
          • dc42undefined
            dc42 administrators @Lyr3x
            last edited by dc42

            @Lyr3x do you have a cancel.g file and/or a stop.g file in /sys, or not?

            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

            1 Reply Last reply Reply Quote 0
            • chrishammundefined
              chrishamm administrators @Lyr3x
              last edited by chrishamm

              @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.

              Duet software engineer

              1 Reply Last reply Reply Quote 0
              • dc42undefined
                dc42 administrators @Lyr3x
                last edited by

                @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

                Lyr3xundefined 1 Reply Last reply Reply Quote 1
                • Lyr3xundefined
                  Lyr3x @dc42
                  last edited by Lyr3x

                  @dc42 Sorry for the late reply. Was very busy in the last days.

                  I have a stop.g in 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.g is missing, then something like M568 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!

                  chrishammundefined 1 Reply Last reply Reply Quote 0
                  • chrishammundefined
                    chrishamm administrators @Lyr3x
                    last edited by chrishamm

                    @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.

                    Duet software engineer

                    Lyr3xundefined 1 Reply Last reply Reply Quote 0
                    • Lyr3xundefined
                      Lyr3x @chrishamm
                      last edited by Lyr3x

                      @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, reflect heat.heaters[1] the heater of the tool#1.

                      Will check the tools object 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 wrong active and standby values.

                      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"
                                  }
                              ]
                          }
                      }
                      

                      a5f32d19-36cb-49d1-ae16-1ea60aaa949e-image.png

                      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 🙂

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post
                      Unless otherwise noted, all forum content is licensed under CC-BY-SA