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

    Yet another heater fault issue

    Scheduled Pinned Locked Moved Solved
    Using Duet Controllers
    2
    6
    355
    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.
    • jens55undefined
      jens55
      last edited by jens55

      I recently posted about 'blips' in the temperature graph on one of my printers while other printers were not showing any of these blips. That problem is still not resolved but now I have moved on to bigger issues.
      On a different printer, I am running multiple jobs that take about 6.5 hours to complete. During most of the time, the temperature curve is flat but at random I have now seen three temperature failures. I can watch this printer for hours and then when I am not watching, it screws up and stops with a temperature fault. It's getting way beyond what it acceptable.
      It doesn't happen at a particular time in the print and I have not found any sort of pattern or correlation to what is going on. This time it is a Duet2 wifi with a Duex5 attached and the sensor is a PT1000.
      There are no hiccups involved.
      Here is a recent m122 which seems perfectly normal:

      2024-02-10, 2:41:22 p.m. === Diagnostics ===
      RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5.0-rc.3 (2024-01-24 17:56:24) running on Duet WiFi 1.02 or later + DueX5
      Board ID: 0JD0M-9P6B2-NJ4S4-6J9DA-3SD6R-KV12L
      Used output buffers: 1 of 26 (26 max)
      === RTOS ===
      Static ram: 23224
      Dynamic ram: 74852 of which 0 recycled
      Never used RAM 11564, free system stack 112 words
      Tasks: NETWORK(1,ready,32.2%,201) HEAT(3,nWait 5,0.2%,287) Move(4,nWait 5,4.3%,261) DUEX(5,nWait 5,0.0%,19) MAIN(1,running,63.4%,691) IDLE(0,ready,0.0%,30), total 100.0%
      Owned mutexes: WiFi(NETWORK) HTTP(MAIN)
      === Platform ===
      Last reset 62:19:10 ago, cause: software
      Last software reset at 2024-02-08 00:21, reason: StuckInSpinLoop, Gcodes spinning, available RAM 11788, slot 1
      Software reset code 0x4083 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x200027d0 Task NETW Freestk 4294966971 ok
      Stack: 00000000 00000000 000008d0 00000000 20005a28 00440193 0044c20e 41070000 2000cecc 00000001 2000cecc 00000000 20004c44 00000000 a5a5a5a5 20008d10 00440193 65c41e7d 20008088 12a7cc04 00000075 00000001 0040c5d5 3f317200 b5dda71c 388ab355 20008d10
      Error status: 0x04
      MCU temperature: min 27.6, current 28.5, max 30.1
      Supply voltage: min 23.9, current 24.1, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes
      Heap OK, handles allocated/used 99/3, heap memory allocated/used/recyclable 2048/1204/1120, gc cycles 0
      Events: 3 queued, 3 completed
      Driver 0: standstill, SG min 0
      Driver 1: standstill, SG min 0
      Driver 2: standstill, SG min n/a
      Driver 3: standstill, SG min 0
      Driver 4: standstill, SG min n/a
      Driver 5: standstill, SG min 0
      Driver 6: standstill, SG min 0
      Driver 7: standstill, SG min n/a
      Driver 8: standstill, SG min n/a
      Driver 9: standstill, SG min n/a
      Driver 10:
      Driver 11:
      Date/time: 2024-02-10 14:41:03
      Cache data hit count 4294967295
      Slowest loop: 28.10ms; fastest: 0.13ms
      I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
      === Storage ===
      Free file entries: 8
      SD card 0 detected, interface speed: 20.0MBytes/sec
      SD card longest read time 9.0ms, write time 2.6ms, max retries 0
      === Move ===
      DMs created 83, segments created 27, maxWait 1029438ms, bed compensation in use: mesh, height map offset 0.000, max steps late 1, ebfmin -1.00, ebfmax 1.00
      no step interrupt scheduled
      Moves shaped first try 1508, on retry 20, too short 12163, wrong shape 49223, maybepossible 3752
      === DDARing 0 ===
      Scheduled moves 266800, completed 266800, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
      === Heat ===
      Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
      Heater 0 is on, I-accum = 0.1
      Heater 1 is on, I-accum = 0.5
      === GCodes ===
      Movement locks held by HTTP
      HTTP is ready with "m122" in state(s) 0 31, running macro
      Telnet is idle in state(s) 0
      File is idle in state(s) 0
      USB is idle in state(s) 0
      Aux is idle in state(s) 0
      Trigger is idle in state(s) 0
      Queue is idle in state(s) 0
      LCD is idle in state(s) 0
      Daemon is idle in state(s) 0
      Autopause is idle in state(s) 0
      Q0 segments left 0
      Code queue 0 is empty
      === Filament sensors ===
      check 240923731 clear 643995180
      Extruder 0 sensor: ok
      === DueX ===
      Read count 0, 0.00 reads/min
      === Network ===
      Slowest loop: 29.64ms; fastest: 0.07ms
      Responder states: HTTP(0) HTTP(0) HTTP(1) FTP(0) Telnet(0)
      HTTP sessions: 2 of 8
      === WiFi ===
      Interface state: active
      Module is connected to access point
      Failed messages: pending 0, notrdy 0, noresp 0
      Firmware version 2.1beta6
      MAC address e0:98:06:22:c9:0c
      Module reset reason: Turned on by main processor, Vcc 3.39, flash size 2097152, free heap 39452
      WiFi IP address 192.168.1.162
      Signal strength -42dBm, channel 1, mode 802.11n, reconnections 0
      Clock register 00002002
      Socket states: 0 0 3 0 0 0 0 0

      Here is a recent temperature graph:

      Screenshot from 2024-02-10 14-56-41.png

      The printer goes along and does it's thing then it throws a hissy fit. A sharp rise or fall in temperature followed by a normal heater response where the temperature returns to normal. In this particular case you can see a huge spike at 14:56 - this is unusual and happened at the instant that I took a snapshot of the graph. All the other faults involved a sudden spike or drop but not as severe as this spike.
      When the system faults out, the spikes might be as high as 50C either positive or negative. The erratic behaviour might continue for a minute or two. Sometimes everything goes back to normal with a steady temperature and other times the printer stops with a heater fault.
      My current print has stopped twice with a fault and this is over maybe a three hour active print time.
      I have not replaced the PT1000 yet. It certainly appears as a random sensor fault because of the speed of the spike but based on the temperature blips on my other printer where sensor replacement did not help, I am reluctant to replace this sensor.
      Looking at my temperature graph right now, I see an essential flat line over the entire graph.

      OOPS, this was with the printer still paused from the last fault - I had restarted the heater but had not yet restarted the print job. I guess I can say that the faults only happen while actively printing

      It is VERY frustrating !!!

      1 Reply Last reply Reply Quote 0
      • jens55undefined
        jens55
        last edited by

        Anybody ever work out a way of mounting two sensors on the hot block?

        1 Reply Last reply Reply Quote 0
        • jens55undefined
          jens55
          last edited by

          I have seen a couple more instances of open circuits causing a heat fault so I am leaning towards the issue being a bad connection someplace. I have started to replace connectors and started another print job to see what happens over the print run. The first connector I replaced had terminals that were different from the terminals that came with the replacement connector. They should still work but we will see what happens. I need to print many of this particular print so I can just replace one connector at a time until I get this sorted. There is the connector on the board and two additional male/female joints so many opportunities of a bad crimp or bad connection someplace.

          1 Reply Last reply Reply Quote 0
          • jens55undefined
            jens55
            last edited by jens55

            I am happy to report that the issue seems fixed. The printer has been going for a bit over an hour and nothing untoward has happened (knock on wood). Hopefully it's because I replaced the connector rather than just having moved things a bit and re-establishing a good connection.
            I can't believe that the first connector I replaced was the dud one - I fully expected to replace each and every connector with the last one being the problem ....

            It amazes me how quickly things went from a bit of a jumpy temperature graph to a single heater fault to 8 or so faults on my last print.

            BTW, for a 215C set point, the temperature fluctuates between roughly 214 to 216 with the vast majority being between 214.8 and 215.4.

            T3P3Tonyundefined 1 Reply Last reply Reply Quote 3
            • T3P3Tonyundefined
              T3P3Tony administrators @jens55
              last edited by

              @jens55 i am glad you got to the bottom of it. that graph does look like a classic bad connection somewhere in the system. If it does come back then the other possibility (other than a connector) which is more sinister is actual fractured, and partially connecting wiring.

              www.duet3d.com

              jens55undefined 1 Reply Last reply Reply Quote 0
              • T3P3Tonyundefined T3P3Tony marked this topic as a question
              • T3P3Tonyundefined T3P3Tony has marked this topic as solved
              • jens55undefined
                jens55 @T3P3Tony
                last edited by

                @T3P3Tony
                Note that the issue with my other printer still exists and is giving me many many hiccups. I am not too concerned with the temperature bumps any more but the hiccup issue concerns me.

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