Bed Heater stops heating causing Paused printing heater fault
-
I recently updated to latest build of 3.2 towards the middle of January. Can't say if thats when it all started but after maybe 15-20 minute of printing. I'd get a Error: Heater fault. Of course how soon this error happened was sporadic. Which now I believe I contribute to the beds temp. A higher temp of say 120C errors out faster than say 60C. I tried several things along the line of calibrating the bed heater and making sure the order of the config for heating was correct based on data in Gcode info page.
I know believe its not a heater issue but a slicing interpretation issue. To verify I created a cube of known size by checking layer height in slicker and extruding in fusion360 the layer height by 60 so I'd know I should have 60 layers. When I import the file into Duet Web Control and start job. They all report back 17 layers even if layer count is less than 17. I use Simplify3D as my primary slicer. I also tried Raise3D's IdeaMaker and it as well created Gcode files that display 17 layer when you go to print. If you use the gcode Viewer and spread lines you can see there are more than 17 layers. Any clue as to either why the heater stops heating or why the Web Control GUI is currently always reporting 17 layers on all files. Older files that were already imported prior to update show correct layer count in GUI.
-
I'm thinking once it hits layer 17 it turns off the bed heater. When it faults I even tried M562 P0 to reset the fault. Then input a new temp both in the GUI and via M140 S120 to turn bed back on to 120. I also clicked the heater into standby, Off and then active again. Nothing allows the bed heater to come back on until after the print errors / finishes or you cancel. Then you can turn run another job that shows yet again only 17 layers and the heater will turn on. I've also turned the heater on manually without printing anything and left on for 4 hours. So no actual issues with heater.
-
Can you post your config.g?
Can you post the entire gcode file or at least the first 50 or so lines of it?
Can you send M122 and post the results?
Can you send M98 P"config.g" and post the results? -
@Phaedrux said in Bed Heater stops heating causing Paused printing heater fault:
M122
This was the M122 at the time the machine was running and stopped heating.
2/5/2021, 7:56:00 AM M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.2 running on Duet WiFi 1.02 or later
Board ID: 08DGM-9T6BU-FG3SD-6J9D2-3SJ6T-9AJRH
Used output buffers: 14 of 24 (18 max)
=== RTOS ===
Static ram: 23460
Dynamic ram: 74164 of which 224 recycled
Never used RAM 14232, free system stack 117 words
Tasks: NETWORK(ready,163) HEAT(blocked,309) MAIN(running,448) IDLE(ready,19)
Owned mutexes:
=== Platform ===
Last reset 01:01:58 ago, cause: software
Last software reset at 2021-02-05 06:53, reason: User, GCodes spinning, available RAM 14432, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 38.6, current 39.4, max 40.3
Supply voltage: min 22.7, current 23.9, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: position 11600, ok, SG min/max 0/1023
Driver 1: position 11531, standstill, SG min/max 0/1023
Driver 2: position 20698, standstill, SG min/max 0/173
Driver 3: position 0, ok, SG min/max 0/1023
Driver 4: position 0, standstill, SG min/max not available
Driver 5: position 0
Driver 6: position 0
Driver 7: position 0
Driver 8: position 0
Driver 9: position 0
Driver 10: position 0
Driver 11: position 0
Date/time: 2021-02-05 07:55:58
Cache data hit count 4294967295
Slowest loop: 66.03ms; fastest: 0.11ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 3.1ms, write time 5.4ms, max retries 0
=== Move ===
DMs created 83, maxWait 2313771ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 5612, completed moves 5590, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state 3
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.7
Heater 1 is on, I-accum = 0.4
=== GCodes ===
Segments left: 1
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is doing "G1 E-0.2000 F1800" 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
Code queue is empty.
=== Network ===
Slowest loop: 51.22ms; fastest: 0.00ms
Responder states: HTTP(2) HTTP(2) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8- WiFi -
Network state is active
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.25
WiFi MAC address ec:fa:bc:25:34:cd
WiFi Vcc 3.46, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 22384
WiFi IP address 192.168.29.47
WiFi signal strength -38dBm, mode 802.11n, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 4 4 0 0 0 0 0 0
- WiFi -
-
box3.gcode Vase32-2.gcode config.g
Vase32-2.gcode is newer import Job that reports in the GUI as 5mm tall. I noticed all ones that come back as only 17 layers will say 5mm high in GUI.
box3.gcode was a test file that I believe was uploaded prior to upgrading to version 3 of Duet firmware running on a Duet2 Wifi.
Config.g of course is my configuration. I have a couple different entries for the heater with the others commented out as I was trying bang-bang heating to see if it made a difference. This was prior to me figuring out its likely to do with the layer limit issue.
-
@Phaedrux said in Bed Heater stops heating causing Paused printing heater fault:
M98 P"config.g"
FYI, I accidentally typed a letter "C" at the beginning of my config.g file when I paste it into a doc for upload. That is not in my config file on the machine.
M98 P"config.g"
HTTP is enabled on port 80
FTP is disabled
TELNET is enabled on port 23
Warning: Heater 2 appears to be over-powered. If left on at full power, its temperature is predicted to reach 598C -
Please post your config-override.g
You have a M307 for the bed and then also load the config-override.g at the end of config.g with a M501. So whatever you have in config-override.g may be overriding the M307 you've pasted into config.g
M308 S0 P"bedtemp" Y"thermistor" T100000 B4138
B4138 is unlikely the correct beta value for your thermistor. Do you know what type you have? B3950 is more likely if it's a generic thermistor. -
For the object height problem it's likely due to the Z moves in your start and end gcode.
G90 M82 M106 S255 M140 S120 M190 S120 M104 S270 T0 M104 S0 T1 M109 S270 T0 G21 ; Metric Values G28 home all G1 H2 XY Z15.0 F9000.00 ;Go to corner for purging M116 ;Wait for all temps G1 E50 F300 ;Purge 50mm Filament G10 ;Retract Filament G1 H2 X150 Y150 Z10 F5000 ;Go to Middle for Probe position G30 ;Recalculate Z height G1 H2 XY Z5.0 F5000 ;Go to corner for printing G11 ;prepare filament to tip G92 E0 ;Reset Extruded Length to Zero G29 S1 ;Load Saved height Map M117 "Printing." ;Text to display webpage statusFirst, don't use H2 on any of these moves. H2 should only be used in cases where you want to ignore the homed state of the axis and force a movement such as in a homing file where you want to force raise the Z axis to allow for clearance of the XY axis during homing. Not appropriate in this context.
Second, you can add a ;E comment to those moves to have DWC ignore the Z component. That's usually enough.
-
Thanks I will test and try different. These were somewhat stock start and stop movements for my Raise3D printer when it was controlled via stock marlin board. The only thing I changed recently was to breakup the Z move on the end so it wasn't moving down until after it moved to xy home. Then again makes sense I'd have to change something since this is Duet logic and not marlin so stands to reason they'd react differently.
-
Ok so this is interesting. After cleaning up my End script. I've found whatever I put on the Z value for the G1 move is what it will report back as the height of the object in the GUI of Duet Web Control. Going to turn this in as a bug. For time being I'm going to remove the Z move on the Ending script so I can print without issue. As you see above in Phaedrux screenshot shared my Z height was Z5. All the items were saying they were 5mm tall with 17 layers of course since i had a .3 layer height. I just changed my current End script from first line to the 2nd line. Guess what. GUI now says objects is 220MM tall when it was saying it was 5mm tall. When in reality its 81MM tall.
G1 XY Z5.0 F5000 ;Go to corner for printing
G1 XY Z220 F5000 ;Go to corner for printingPhaedrux, Thank you for the help. I would have never thought to dig into my end script. I figured maybe the start script could mess with it but not the end. Literally if its at the end I assumed it already read over the whole file so no way it'd throw off row count. Guess thats bad on my part to make an assumption like that. I'll post back what Duet says on ticket.
-
Link for anyone wanting to following the issue I submitted.
-
I think it's reading from the back of the file looking for the last z move to get the height.
One way around it is to put your start and end gcode into the start.g and stop.g files. Start.g gets called before the print gcode file starts and stop.g gets called by having M0 in your end gcode section in the slicer. You can also call custom macros from the start and end gcode section of the slicer with M98.
