Duet Stops mid print
-
Hi,
This is a long shot.
I had a similar problem with a Z axis position sensor that I was experimenting with. All it was supposed to do was run trigger7.g, which it normally did.
But during printing it instead caused a reset when the printing reached the point where the sensor was activated. It DID NOT run the trigger7.g file when this happened.
I never found out why.
Frederick
-
@BlueDust, it might be waiting to write to USB. I've see this happen. Usually the print continues but does a few moves, pauses, does a few more moves, pauses again and so on. It only happens on some Gcode files. It's fixed in 2.05RC1.
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 -
@dc42
I first noticed this issue on 2.05 rc1, and downgraded back to 2.04 thinking it would work. Also, this is not a short pause. I let it sit for over 30 min trying to see what I could do... It never moved. -
I am not saying this is "fixed" yet, but I replaced the MicroSD card and I am on my 3rd print (2nd attempt) with no issues so far. (2nd print failed because the filament was large and caused a clog, but that's not the Duet2's fault,... I also re enabled the filament monitor...).
If this works out, I will re print one of the failed gcode files.
Thanks!
-
I have been printing without a single freeze (since I replaced the SD card) until now.
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.04 running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DGM-9T6BU-FG3S0-7JTDL-3SN6N-TS6VG
Used output buffers: 4 of 24 (12 max)
=== RTOS ===
Static ram: 25680
Dynamic ram: 93444 of which 0 recycled
Exception stack ram used: 652
Never used ram: 11296
Tasks: NETWORK(ready,628) HEAT(blocked,1232) DUEX(suspended,160) MAIN(running,1300) IDLE(ready,200)
Owned mutexes:
=== Platform ===
Last reset 00:40:27 ago, cause: software
Last software reset at 2019-12-07 01:32, reason: User, spinning module GCodes, available RAM 11408 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 8
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 72.8ms, max retries 0
MCU temperature: min 38.3, current 39.0, max 39.4
Supply voltage: min 23.5, current 24.1, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max 0/293
Driver 1: standstill, SG min/max 0/233
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max 0/250
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 0/141
Driver 8: standstill, SG min/max 0/94
Driver 9: standstill, SG min/max 0/127
Date/time: 2019-12-07 02:12:48
Cache data hit count 4294967295
Slowest loop: 100.26ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 1623052, FreeDm: 82, MinFreeDm: 82, MaxWait: 876790ms
Bed compensation in use: mesh, comp offset 0.000
=== DDARing ===
Scheduled moves: 3606, completed moves: 3584, StepErrors: 0, LaErrors: 0, Underruns: 0, 1
=== 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.4
=== GCodes ===
Segments left: 0
Stack records: 3 allocated, 0 in use
Movement lock held by aux
http is doing "M24" 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) 18
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: 296.84ms; 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 251.02, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0Fun, that 3 letter word with "u" in the middle.
-
Printer is stopping a lot today.
Any help with troubleshooting the issue would be great!Anyway to have YAT or a log file on the printer spit out all the gcode and debug as Duet2 prints? I want to see what it lasts stops on. I have a single print that happens a lot. Pause, reboot printer, recover print, and happens again some random time down the road. I can share it if you like... 201901MosaicKeychain2 test.maf.gcode
Fun, that 3 letter word with "u" in the middle.
-
This is happening in 2.04 and 2.05r2
-
This duet2 pause or lockup issue does not happen on all prints, and prints it does occur, it doesnt happen on the same spot during the print (if I reprint the same gcode file over a few times). But might occur on the same spot different layer of I can get it started again using the pause/recovery feature of the printer. Yes pause data gets recorded but doesn't move to x0y0 as it does when I normally press that button...
-
@BlueDust said in Duet Stops mid print:
201901MosaicKeychain2 test.maf.gcode
Are you using a pallete2?
-
@Phaedrux
Sorry for the delay in my response. I am getting frustrated with this issue and then my PC's NIC decided to die. Eh, it was 7 years old. Built a new PC over the weekend, and I should be able to get back to playing with this, this week.
I have a Palette2 but use it in accessory mode and haven't test connected mode using an RPi. I prefer accessory mode as I lose the Duet2 features/control in connected mode. But I am planning on testing connected mode if this isn't resolved soon.
This problem happens when using the Palette2 gcode or not, and not on every print. I have been printing small D&D characters (S3D to Duet2, no Palette2) and some print OK and others do not. The Gcode file I shared was also sliced in S3d and then updated for color in Chroma. I shared it was because it was the most recent file with the problem. I can share another D&D model with the issue too... But only tried that one once so far.The issue "appears" that if a gcode file works, it just works, but if it's bad, it's bad most (haven't tested enough) if not everytime I try to print that same gcode. Early on with this problem, I created the same Gcode file 3 times before the object would print.
The odd part is, that if the problem occurs, it appears to stop on the same spot each time (pause reset printer, resume) just a different (appears) random layer. But if I print it again using the same Gcode file, that spot moves to a different spot. It's weird and I am actually trying to print around this problem so I haven't tested this more then a few times for consistency on the same Gcode (the one I shared). -
@Phaedrux
I just re read what I wrote on my last message. I wrote it on my phone and need to stop doing that... It would appear I need English lessons from my 8 year old daughter.Let me know if you have any other ideas or things I can look at. I tried to upload another gcode file that also had this issue but it was too big, even after trying to ZIP it.
Thanks for your help.
-
@BlueDust said in Duet Stops mid print:
Hiccups: 1623052
I just noticed that you have an insanely high number of hiccups being reported in that last M122.
Hiccups: 14280857
Even higher before that.
Can you post your config.g again? Are you using microstepping values higher than x16?
Can you use dropbox or something to share the gcode file?
-
Looking at your config from one of your older posts https://forum.duet3d.com/topic/12941/auto-bed-leveling-went-bad?_=1576682639924
I see that you're indeed using x256 microsteps for all axis and extruder. This will greatly limit your maximum speed before the step pulse generator is overwhelmed and hiccups occur.
For best results it's recommended to use x16 microstepping with interpolation to x256 enabled. This reduces the load on the CPU and still allows the drivers to use x256 microstepping for the motors.
-
@Phaedrux
I have had this configuration since I first setup the Duet2 last year.
M350 X256 Y256 Z256 I0 ; Configure microstepping without interpolation
M350 E16 I1 ; Configure microstepping with interpolationDid something change in the 2.04+ ( I haven't tried older versions when testing this issue) to make this now cause an issue and the problem mentioned. Or are you saying what I have is not proper config (and causing errors... er Hiccups) and should be fixed. Possibly contributing to this problem.
As always. Thanks!
-
@BlueDust said in Duet Stops mid print:
should be fixed. Possibly contributing to this problem.
Yes. It's not recommended to use x256 microstepping for all axis. It will likely result in high hiccup counts which may result in unexpected behaviour. I'm not sure if something changed in recent firmwares to make the lockup issue more prevalent, or if it has something to do with the Pallette 2 and the way it uses ping/pong pulses of the extruder that could be causing some issues.
Regardless, you'll likely see better behaviour by using x16 microstepping with x256 interpolation.
-
OK...
Trying to setup x16 w/Interpolation...Should x16 with I be enabled for all axis? Are you saying that Z can be x256, but the rest should be X16 w/ i?
I just setup x16 with Interpolation for all axis and am just asking to confirm best practice on what should or shouldn't be x16i or x256.
Thanks!
-
@BlueDust Iād go with all on x16i.
Ian
-
I am now getting a higher pitch squeal on the Z axis when moving at speed. Other axis are also slightly louder, but haven't printed anything yet... Just getting setup to do so...
Is there a way to stop this sound other than slowing it down to a crawl?hmmm...
I don't think I enabled Silent Step or anything. Its been awhile since I setup the initial config to remember all the details... Something to look into...Fun, that 3 letter word with "u" in the middle.
-
M350 X16 Y16 Z16 E16 I1And adjust the M92 steps per mm accordingly.
Just as an aside to make testing alternative microstepping easier, if you set the microstepping to x16 first and then set the steps per mm accordingly for x16, you can then change the microstepping on a later line and the firmware will automatically calculate the steps per mm for you.
example:
M350 X16 Y16 Z16 E16 I1 M92 X80 Y80 Z400 E410 M350 E256That would leave the XYZ using x16i and set the extruder as x256 and you wouldn't need to alter the M92 at all.
This should make it easier to experiment.
-
@BlueDust said in Duet Stops mid print:
getting a higher pitch squeal on the Z axis when moving at speed
What are the commands you are using? Did you remember to recalculate your steps per mm?
