does not completely finish the last layer of the print 3.5.0-b4
-
@gloomyandy I don't think so. It happens not every time and I am not sure if I want to wait for the next crash, it might damage my printer and products, so I am not willing to risk with my customers parts. I have downgraded to RRF 3.4.6, will see if the problem re-occurs or not. But if it will, I will definitely capture M122 output.
-
I noticed this same symptoms. Job would complete and complete all my end gcode, heaters would be off, head positioned as requested. But web interface would still say printing. I noticed that Iād I closed my browser, cleared the cache with just google loaded, then launched dwc and it showed normal.
-
-
@blt3dp @Arminas I have created this Github issue https://github.com/Duet3D/RepRapFirmware/issues/899.
-
@dc42 Quick update - after downgrading to RRF 3.4.6, this problem does not occur anymore. So I guess it has something to do with a firmware.
-
@Arminas have you tried 3.5.0-rc.1 ? I had a similar issue with beta 4 occasionally but so far not with rc1. One of the bugs we fixed in rc1 may have been causing it.
-
@dc42 not yet. I will do that next week.
-
@Arminas thanks, that would be helpful.
-
@dc42 I have upgraded the firmware to 3.5.0-rc.1 and during the printing process, some strange movement on the outer perimeter occurred again (not at every layer, just for the couple layers in different position. I did not wait for the part to finish, I pressed Pause and typed M122 (don't know if it works that way to see if anything is strange):
M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.5.0-rc.1 (2023-08-31 16:16:56) running on Duet 3 Mini5plus WiFi (standalone mode)
Board ID: ZNS47-R396U-D65J0-40KM0-MR03Z-H3B3X
Used output buffers: 1 of 40 (19 max)
=== RTOS ===
Static ram: 102836
Dynamic ram: 121740 of which 0 recycled
Never used RAM 12976, free system stack 128 words
Tasks: NETWORK(2,nWait,12.5%,228) HEAT(3,nWait,0.1%,329) Move(4,nWait,2.0%,240) CanReceiv(6,nWait,0.0%,939) CanSender(5,nWait,0.0%,337) CanClock(7,delaying,0.0%,342) TMC(4,nWait,1.3%,108) MAIN(1,running,82.8%,700) IDLE(0,ready,0.5%,29) AIN(4,delaying,0.9%,264), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:52:39 ago, cause: power up
Last software reset at 2023-09-23 12:52, reason: User, Gcodes spinning, available RAM 13560, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
MCU revision 3, ADC conversions started 3159303, completed 3159302, timed out 0, errs 0
MCU temperature: min 28.8, current 33.5, max 35.1
Supply voltage: min 23.5, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/1, heap memory allocated/used/recyclable 2048/12/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, read errors 0, write errors 0, ifcnt 13, reads 25001, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 1: standstill, SG min 0, read errors 0, write errors 0, ifcnt 13, reads 25001, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 2: standstill, SG min 0, read errors 0, write errors 0, ifcnt 12, reads 25002, writes 12, timeouts 0, DMA errors 0, CC errors 0
Driver 3: standstill, SG min 0, read errors 0, write errors 0, ifcnt 12, reads 25002, writes 12, timeouts 0, DMA errors 0, CC errors 0
Driver 4: standstill, SG min 0, read errors 0, write errors 0, ifcnt 13, reads 25001, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 5: standstill, SG min 0, read errors 0, write errors 0, ifcnt 13, reads 25001, writes 13, timeouts 0, DMA errors 0, CC errors 0
Driver 6: standstill, SG min 0, read errors 0, write errors 0, ifcnt 10, reads 25004, writes 10, timeouts 0, DMA errors 0, CC errors 0
Date/time: 2023-09-23 13:59:16
Cache data hit count 4294967295
Slowest loop: 219.42ms; fastest: 0.10ms
=== Storage ===
Free file entries: 18
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 8.8ms, write time 2.1ms, max retries 0
=== Move ===
DMs created 83, segments created 42, maxWait 29924ms, bed compensation in use: mesh, height map offset 0.000, ebfmin -1.00, ebfmax 1.00
no step interrupt scheduled
Moves shaped first try 3129, on retry 1088, too short 14104, wrong shape 10449, maybepossible 1115
=== DDARing 0 ===
Scheduled moves 34591, completed 34591, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 3], CDDA state -1
=== DDARing 1 ===
Scheduled moves 0, completed 0, 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.4
=== GCodes ===
Movement locks held by null, null
HTTP is idle in state(s) 0
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
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x0000807
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 28432, received 0, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 26 (min 26), ts 15797/0/0
Tx timeouts 0,0,15796,0,0,12634 last cancelled message type 30 dest 127
=== Network ===
Slowest loop: 183.65ms; fastest: 0.00ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
=== WiFi ===
Interface state: active
Module is connected to access point
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 1.25
MAC address f0:08:d1:03:76:dc
Module reset reason: Power up, Vcc 3.34, flash size 2097152, free heap 26608
WiFi IP address 192.168.32.190
Signal strength -59dBm, channel 0, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0P.S. - I am printing in high speed this time, 200 mm/s, I don't think that speed has something to do with it, but just in case.
I can see and hear that extruder wheel is doing something strange on the corner, movement is not smooth and it extrudes more material than it should (it is not a start point). Don't mind the infill, I am experimenting with fast printing speed.
Also, Input Shaping is activated.
-
@dc42 Downgraded to 3.4.6 again, no issues. Input Shaper activated, same speed. I don't know if something is wrong with my setup/config, but 3.5.0 rc1 does not work for me
-
@Arminas You seem to have had the same problem as I am having.
I noticed when I looked over the print, the blobs were caused by the printhead stopping for a fraction of a second, so residual pressure in the hotend was extruding plastic on the one area, causing the blob.
-
@Arminas said in does not completely finish the last layer of the print 3.5.0-b4:
@dc42 Most of the time, after the printing process, DWC shows that printing is paused and I have to press cancel the print, although it's finished, but heaters are turned off.
Today it happen again, and even worse. I was looking at the last layer being finished, and couple of seconds before the end, print bed moved up very fast and crashed into the part, melting the hole into the part with hot nozzle.... Luckily, I was standing next to the printer and turned it off as fast as I could.
@dc42 i just had this very issue with 3.5rc1. (also had similar issues with the beta versions before, but was blaiming bad settings or something since it didn't always happen) I had to turn the printer off immediately to prevent any further damage after the nozzle crashed into the print.
-
@Threepwood This might be a different issue now. To sum up, during my last RRF upgrades to 3.5.0. Beta and 3.5.0 RC, I had several issues (maybe all are related):
- Printer did not finish the last few lines, but there was no printhead crashing into the part.
- In the middle of the print, extruder used to extrude backwards for a couple of seconds, but there was no printhead crashing into the part.
- Everything was good, but at the very last lines printhead crashed into the part.
Well, all issues are related with the unwanted movement of the printhead/extruder.
-
@Diamondback same here. Now I am using 3.4.6 latest firmware with input shaper results, no issues.
-
Any news on any of this? I have a hunch the crashing part is related to whether or not I paused the print at some point... I don't really want to test this idea though, the stuff is too expensive to keep destroying Revo nozzles from crashes...
-
@Diamondback I went back to RRF 3.4.6 and don't have any problems now. I just know that I had extruder crashes with RRF 3.5.0-b, I had blobs on the corners with RRF 3.5.0-rc1 and now I have zero issues with RRF 3.4.6. I would be glad to search what causes these issues with new firmware, but I am trying to run a 3d printing business and don't really have time for this. Also, I am afraid to brake some parts of extruder...
-
@Diamondback you could try the new build at https://www.dropbox.com/scl/fo/tjznycpk7bv7sj71p0ssl/h?rlkey=096p4nvgmigyrb20jj8olg3wu&dl=0. I wasn't able to replicate your issue exactly, but I did replicate and fix another, possibly related, issue with print jobs not quite completing.
-
@dc42 said in does not completely finish the last layer of the print 3.5.0-b4:
@Diamondback you could try the new build at https://www.dropbox.com/scl/fo/tjznycpk7bv7sj71p0ssl/h?rlkey=096p4nvgmigyrb20jj8olg3wu&dl=0. I wasn't able to replicate your issue exactly, but I did replicate and fix another, possibly related, issue with print jobs not quite completing.
Will do. Does this also include the fix for the not quite finished print?
( https://forum.duet3d.com/post/325940 ) -
@Diamondback that's what I want to know. It may have had the same cause as the issue I was able to reproduce and fix.
-
Ah, sorry, wrong thread I meant to post in the filament monitor one...
-
@dc42 Can you elaborate what sort of condition lead to the SD print not finishing properly? Can you tell what it would do "instead"?
Would it just ignore all the rest of the file? Or just parts of it? What I can imagine given the behavior I saw is that RRF ignored the last few lines of actual extrusion but then executed all the management stuff afterwards (tool deselection, toolhead parking etc)
In that case the headcrash would happen due to the nozzle still being in the middle of the print and Z not being lifted...
Is that something that seems plausible?I really want to understand this issue and help debug it but I'm not really fond of destroying another Revo nozzle...