Heater Temperature Excursion
-
@Phaedrux
it looks like a delta.please post a picture of the printer
-
-
@Phaedrux said in Heater Temperature Excursion:
When do you see stutters in motion?
Forgot to answer this. Usually during long sweeping curves I will see the printer pause for a fraction of a second and continue.
I thought perhaps the CPU is getting overloaded...
-
When you notice it doing that check the m122 for hiccups. Though that's usually only when using microsteps higher than 16 which you are not. Curves with small segments could do it. What slicer do you use? s3d has been known to do that.
Low e jerk and pressure advance could be another possibility.
Do you use mesh compensation? Low z jerk can sometimes cause stutters in xy but you've got a delta so all jerk is the same on xyz so I don't think that's what's going on here.
-
@Phaedrux said in Heater Temperature Excursion:
When you notice it doing that check the m122 for hiccups. Though that's usually only when using microsteps higher than 16 which you are not. Curves with small segments could do it. What slicer do you use? s3d has been known to do that.
I use PrusaSlicer, will do the M122 when I notice the hiccups.
Low e jerk and pressure advance could be another possibility.
Interesting, I don't use pressure advance but I can see why the low E jerk could cause that.
Do you use mesh compensation? Low z jerk can sometimes cause stutters in xy but you've got a delta so all jerk is the same on xyz so I don't think that's what's going on here.
Yes I'm definitely a mesh user. I see how that could cause issues for cartesian users, but I agree probably unrelated for me on a delta.
If I may re-ask the question from a few posts ago: what do you make of the "slowest loop" statistic? Is that not concerning?
-
Unsure of the slowest loop stat. @dc42 would have to comment.
-
I hope this isn't bad form, but it seems this question slipped by so I'm tagging @dc42 again...
-
@Leav said in Heater Temperature Excursion:
I hope this isn't bad form, but it seems this question slipped by so I'm tagging @dc42 again...
No that's fine. Keeps us from forgetting. Thanks for giving it a couple days.
-
Still chasing this, and I've worked on a few things since I last posted:
- New Thermistor (cartridge style, to rule out issues with wires shorting in the heater block)
- New heater cartridge
- Successfully replaced wifi module with esp-07s - Signal went from ~-70dbm to ~-55dbm
Started a five hour print, temperature graph was smooth, minus a few blips which seemed to indicate that the heating process gets "stuck" (??) either in "on" or "off" mode for a second, and the then recovers:
I let it be, thinking this is a minor issue, but after a few hours the excursion hit again:
I was able to resume the print (thanks for such a robust recovery mechanism!), and there was still a bit of noise:
But now it is very smooth (minor blip still shows up):
Does anyone have any clue what could cause this? I feel like this is some sort of random behavior that gets introduced and suddenly vanishes, making debugging very frustrating...
Here is a copy of the M122 response after the recovery:
M122 === Diagnostics === RepRapFirmware for Duet 2 WiFi/Ethernet version 3.1.1 running on Duet WiFi 1.02 or later Board ID: 0JD0M-9K662-MGPSS-6J1FD-3S46N-TVU6Y Used output buffers: 3 of 24 (11 max) === RTOS === Static ram: 27980 Dynamic ram: 93124 of which 48 recycled Exception stack ram used: 576 Never used ram: 9344 Tasks: NETWORK(ready,268) HEAT(blocked,792) MAIN(running,1732) IDLE(ready,80) Owned mutexes: WiFi(NETWORK) === Platform === Last reset 04:52:37 ago, cause: power up Last software reset at 2020-10-16 16:27, reason: User, spinning module GCodes, available RAM 9376 bytes (slot 0) Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN Error status: 0 MCU temperature: min 22.3, current 36.8, max 43.8 Supply voltage: min 23.7, current 24.0, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes Driver 0: ok, SG min/max 42/430 Driver 1: ok, SG min/max 78/423 Driver 2: ok, SG min/max 0/416 Driver 3: ok, SG min/max not available Driver 4: standstill, SG min/max not available Date/time: 2020-10-17 12:48:30 Cache data hit count 4294967295 Slowest loop: 275.25ms; fastest: 0.12ms 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 2.9ms, write time 63.4ms, max retries 0 === Move === Hiccups: 0(0), FreeDm: 161, MinFreeDm: 137, MaxWait: 455270ms Bed compensation in use: mesh, comp offset 0.000 === MainDDARing === Scheduled moves: 215624, completed moves: 215603, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: 3 === AuxDDARing === Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1 === Heat === Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 Heater 0 is on, I-accum = 0.0 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 X-5.074 Y-103.468 E29.61163" 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 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 275.44ms; fastest: 0.00ms Responder states: HTTP(0) HTTP(0) 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.23 WiFi MAC address 48:3f:da:45:74:de WiFi Vcc 3.38, reset reason Unknown WiFi flash size 4194304, free heap 24504 WiFi IP address 192.168.1.6 WiFi signal strength -55dBm, reconnections 0, sleep mode modem Socket states: 4 0 0 0 0 0 0 0 -
Given that on both the negative and positive small excursion you show, the leading edge is 'instantaneous', followed by a real ramp to compensate, it looks like a thermistor issue. The actual temperature cannot change that fast. After a sudden change in the thermistor+wiring resistance, the heater initiates a real ramp + overshoot to compensate. There has to be a loose connection in the thermistor wiring somewhere, I think.
-
This has been suggested before, but I'm willing to give it a try again.
I'll expose the electronics bay and jiggle everything around while holding at ~250c.
Will report back. -
Embarrassed / Happy to say that I found a loose connection deep in the
mines of moriaelectronics bay.Below is the result of wiggling that cable... That cable is very much static during the print, but I guess the vibrations/heat expansion was enough to cause issues?
Lesson of the day: don't use bare wire in screw terminals! (not even "just temporarily to see if it works!")
Thanks all for bearing with me during my somewhat crazy tangents.
