New Random issue
-
For the past week or two, I have found my Duet2 board just stopped mid print. Everything is cold, and the printer is acting like I just turned it on.
All I can see is that the BLTouch is blinking red, and there is no resurrect file.
The last line in the Event Log says the print started, and then the power on steps...
event log started...
date and time set at power on... etcAny ideas would be great!
Thanks!
The below was taken after I found the printer stopped printing and already started to pre-heat the bed/nozzle.
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.03 running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DGM-9T6BU-FG3S0-7JTDL-3SN6N-TS6VG
Used output buffers: 1 of 24 (20 max)
=== RTOS ===
Static ram: 25680
Dynamic ram: 94236 of which 40 recycled
Exception stack ram used: 320
Never used ram: 10796
Tasks: NETWORK(ready,524) HEAT(blocked,1236) DUEX(suspended,156) MAIN(running,3748) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 00:19:00 ago, cause: power up
Last software reset at 2019-06-29 16:45, reason: User, spinning module GCodes, available RAM 10796 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 2.9ms, max retries 0
MCU temperature: min 30.7, current 31.2, max 32.4
Supply voltage: min 21.4, current 24.0, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2019-06-30 18:44:50
Cache data hit count 2954459546
Slowest loop: 63.80ms; fastest: 0.08ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.2
Heater 1 is on, I-accum = 0.6
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 93.95ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state 5, link 100Mbps full duplex
=== Filament sensors ===
Extruder 0: pos -0.02, ok, no calibration data, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0Fun, that 3 letter word with "u" in the middle.
-
Now my BLTouch doesn't work at all. It will not pull the sensor back up. Just blinks its red light.
Could this have been the BLTouch on its way out the door the entire time?
Did it just die on me, or just playing dead? -
Did homing work? Or was it getting stopped when trying to home at the start of the print?
If you send the BLTouch the reset error and retract pin code does it start behaving again?
Double check the wiring.
-
It doesn't move to home Z as it says Z has already been triggered.
Sending the reset code stops it from blinking but the moment you try to move the pin it blinks red again.
If I keep sending the reset code and keep trying to get the pin to move, eventually I may (though rare) get it to move up or down. And right after the pin movement occurs it blinks red again.
-
If the wiring is good, I suspect the probe has an issue
-
It's been working fine since I installed it, about a month ago. Maybe longer. I unplugged and plugged in all the wires again just to make sure they were good.
Wish there was more I could do to test it.
-
@bluedust you could check the continuity of the wires with a multimeter.
-
@phaedrux
Good idea. I can easily fix a bad wire.
Will check and follow tomorrow. -
You could also try taking out the pin via the set screw on the top of the probe body and cleaning it.
-
@phaedrux
The wiring is good. I kept playing with it and it seems now I can get the pin to go down most of the time and it just doesn't go up most of the time. It appears to be stuck or sticking in the down position. But it could also be that the mechanism that pulls it up isn't as strong as it used to be. Sometimes even if I tap it to make sure it's not stuck and should be easily pulled up, doesn't move when I reset the error or send the up command.I remember seeing the screw on the top when I initially installed the BLTouch but forgot it was there. Will look into it. Thanks!
-
Removed the set screw, and the needle fell out. It was clean. Looked new. Looked over the BLTouch and found nothing weird. All looked new, and couldn't find any dirt/dust or anything. I played with it a bit (needle up and down with set screw removed) and put it back together (word of warning, the needle can be fired out the set screw hole a few inches and become lost). Now it just works. Ran it in test mode for about 2 minutes and no issues. I have no idea what to make of it but not complaining.
Thanks @Phaedrux for reminding me about the screw!
-
BLTouch appears to be working again, but I am still losing prints.
Within 30 or 40 minutes of starting a print, I am finding it to appear to have rebooted (log show getting IP and current time). The BLTouch is blinking red. This is the same behavior I found the printer a few times about 5 to 10 days before the BLTouch completely stopped working. But it may be something else and just be blinking because after a reboot, and the nozzle being so close to the bed, the self test the nozzle does would fail because the needle isn't able to completely extend itself. In testing this, the needle, after failing the self test will still gets pulled back up. Is the BLTouch flipping out and the printer is rebooting? Or the printing have another issue and rebooting mid print. When it does reboot, so far it is always within the first 3 layers. I have seen this fail between half way of the first layer and somewhere at the end of the 2nd layer or halfway through the 3rd (just not sure).
Are their any full debug logs that I can enable to see all the printer is doing so when it happens again I can actually see why this is happening?Just to clarify, this isn't happening on all prints. Appears to occur every 3 or 4 prints at the moment....
Thanks!
-
When it does this can you run M122?
You can also enable more detailed logging after that if it doesn't seem to indicate anything helpful.
-
@phaedrux
I posted the details from M122 in my first post. -
-
@bluedust said in New Random issue:
Last reset 00:19:00 ago, cause: power up
Last software reset at 2019-06-29 16:45, reason: User, spinning module GCodes, available RAM 10796 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414dAssuming that you didn't turn power off and on again after you found the printer stopped, that indicates that the board reset due to loss of power. So either you had a power brownout, or your PSU cut out.
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 -
My printer is behind a UPS and the voltage while printing reads 24.1v.
If I lost power wouldn't there be a resume file? Currently when this happens it says their is no resume file. I haven't tested the resume feature completely from a power outage, but thought I had it at least configured to record the resume info to a file. (set it up a while back) I will check to see if that feature is working enough to save the file and get back to you.Thanks!
-
Does the UPS happen to do self tests? I stopped using a ups a long time ago after I happened to be in the room when it did a self test and a print was running. The test managed to make the duet reboot.
-
@phaedrux
Yes. I have it programmed to do weekly self tests. All it does is switch to battery power during the test. I have been using this UPS for more then 5 years and never had it cut power unless it was drained. Also, my NAS is very sensitive to power fluctuations and crashes. (Hence the UPS). If the NAS crashes, I would get an email alert on it's reboot. Also my TV and computer, firewall/router/switch would crash and I would get other notifications.
I currently do not believe my UPS is having output power issues. I will review my UPS power logs to confirm. -
@dc42 said in New Random issue:
Last reset 00:19:00 ago, cause: power up
Last software reset at 2019-06-29 16:45, reason: User, spinning module GCodes, available RAM 10796 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414dIt was a while ago now, but do not believe I reset the printer. But that would make sense to what I see in the logs (getting an IP and correct time).
I just tested out the resume feature after I cut power during a print. And the resurrect.g was created. I clicked my recover macro after one of the previous failures and it said the resurrect.g file didn't exist. I will try this again after the next failure, but also curious on any other ideas or items I can look into.
Are there any verbose logs that I can enable? And/or have the Duet2 board send live logs to a syslog server?Thanks!
