Well after spending most of the day playing around with no success, a can of compressed air over the board, around the sd card slot and ethernet slot and now it's functional.
I've tried to remove and reinsert the card a bunch of times, put a small amount of pressure on the card and reader, let it run to warm up a bit, and it still works.
My Duet Maestro crashed when prepping a print this morning, now I have a diag light and fully unresponsive (including serial) when there is an sd card installed. If I remove the SD card everything works, I can even enter all the GCODE from on config.g over the serial line and it seems to be ok.
I've tried reflashing with BOSSA, replacing the SD card, using the new sd card contents, end result is always the same, diag light on and unresponsive when restarted with an sd card present.
5v and 3.3v lights are lit.
If I insert the SD card after restarting, I see this with M122
Error: SD card speed 30.00Mbytes/sec is unexpected
Again with any sd card.
Any other ideas?
You are absolutely right, R0 not R1! Sorry about that.
Thanks though for the quick response.
And, before I forget. Last released firmware here.
Firmware Name: RepRapFirmware for Duet 2 Maestro
Firmware Electronics: Duet Maestro 1.0
Firmware Version: 2.02(RTOS) (2018-12-24b1)
Web Interface Version: 1.22.6
Web Interface by Christian Hammacher
Licensed under the terms of the GPL v3
I had my first power failure today, and was able to get recovery working with a little bit of effort. I noticed that the generated ressurect.g has a small error in it where it didn't put quotations around the file name when calling M23, so on resume it failed to find the file until I renamed it. At least I think it is for this reason.
; File "Tube 1 (PLA).gcode" resume print after power failure at 2019-04-20 19:34
M140 P0 S60.0
G10 P0 S200 R200
T0 P0
G29 S1
G92 X146.044 Y181.025 Z140.000
M98 Presurrect-prologue.g
M106 P0 S0.00
M106 P2 S1.00
M106 S1.00
M116
M290 S0.080
G92 E0.00000
M83
M23 Tube 1 (PLA).gcode
M26 S11969350 P1.243
G0 F6000 Z142.000
G0 F6000 X146.044 Y181.025
G0 F6000 Z140.000
G1 F6000.0
M24
The result of this was that it tried to load "Tube 1 .gcode" dropping the filename at the '(' character.
Additionally the "M290 S0.080" had an additive effect (as it would normally), so upon re-running M916 after renaming the file it finally succeeded but left a bit of a gap at the first layer until I fixed the stepping, it might be better to use "M290 S0.080 R1" in this case.
This is just selecting the bit in the bitfield and assigning it to a flag called GCONF_INT_RSENSE. It's not setting the value to 1.
Do you see somewhere in the code this flag is used and setting the value to internal?
@gnydick Update to firmware 2.02, there was a bug fixed after RC7 which could explain this.
See here: https://forum.duet3d.com/topic/8250/hiccups-causing-layer-shifts/6
I think this is resolved by firmware 2.02, incorporating the timing fixes. I have not had hiccups or layer shifts in the last 2 days, but I'll keep checking for a couple more just in case.
@dc42 I looked at your commit and I agree that I think it will resolve the problem on the basis that it's similar to what I was going to try myself.
I've been running a couple of hours now with the change and all of the statistics, including custom debug code that I added which caused me to find the bug, all seem to be reporting correctly now.
I'll need to run longer to check if this resolve my other issues with layer shifting, I'll post in that thread if it works.
Thanks for your help.
@dc42 said in StepTimer::GetInterruptClocks isn't incrementing:
ease modify your debug to print start and end in hex, because that may make it easier to see if the problem occurs when the 16-bit timer wraps around.
Thanks! I'll grab the change and test this morning too.
@veti Yeah, I saw that post and believe it is the same issue.
It's possible it's related to a problem with the timer, https://forum.duet3d.com/topic/8264/steptimer-getinterruptclocks-isn-t-incrementing/4
The result from a hiccup with debugging enabled
DDA: start=[55.863998 49.412998 1.015103] end=[57.040001 50.084000 1.016289] s=1.353967 vec=[0.868561 0.495582 0.000876 0.031352 0.000000]
a=800.000000 d=800.000061 reqv=80.000000 startv=50.267147 topv=50.267147 endv=18.985228 sa=0.000000 sd=1.353967
cks=36658 sstcda=58906 tstcddpdsc=58906 exac=0
DMX: not moving
DMY: not moving
DMZ: not moving
And the M122 log
=== Diagnostics ===
RepRapFirmware for Duet 2 Maestro version 2.02RC7(RTOS) running on Duet Maestro 1.0
Board ID: 08DGM-95762-FD3TD-6JTDD-3SW6S-18AZH
Used output buffers: 1 of 20 (15 max)
=== RTOS ===
Static ram: 19484
Dynamic ram: 97416 of which 0 recycled
Exception stack ram used: 388
Never used ram: 13784
Tasks: NETWORK(ready,632) HEAT(blocked,1320) MAIN(running,1792) IDLE(ready,200)
Owned mutexes:
=== Platform ===
Last reset 02:28:09 ago, cause: software
Last software reset time unknown, reason: Hard fault, spinning module Platform, available RAM 13656 bytes (slot 1)
Software reset code 0x0030 HFSR 0x40000000 CFSR 0x02000000 ICSR 0x04432803 BFAR 0xe000ed38 SP 0x200039ec Task 0x4e49414d
Stack: 004184ed 004184f4 61000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffffffff 00000032 00000010 20001b68 200062f0 a5a5a5a5 00f9c4ff a5a5a5a5 a5a5a5a5 a5a5a5a5 0043d983 0045ac20 0045faa4
Error status: 2
Free file entries: 9
SD card 0 detected, interface speed: 15.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 40.5, current 41.6, max 42.3
Supply voltage: min 23.0, current 23.0, max 23.1, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: ok, read errors 0, write errors 0, ifcount 17, reads 64865, timeouts 0
Driver 1: ok, read errors 0, write errors 0, ifcount 17, reads 64865, timeouts 0
Driver 2: ok, read errors 0, write errors 0, ifcount 216, reads 64865, timeouts 0
Driver 3: ok, read errors 0, write errors 0, ifcount 187, reads 64863, timeouts 2
Driver 4: ok, read errors 0, write errors 0, ifcount 216, reads 64865, timeouts 0
Driver 5: ok, read errors 0, write errors 0, ifcount 0, reads 0, timeouts 64866
Driver 6: ok, read errors 0, write errors 0, ifcount 0, reads 0, timeouts 64865
Date/time: 2018-12-22 22:34:41
Slowest loop: 4581229.00ms; fastest: 0.11ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0
=== Move ===
Hiccups: 1, StepErrors: 1, LaErrors: 0, FreeDm: 137, MinFreeDm: 125, MaxWait: 0ms, Underruns: 0, 0
Steps: 64670372, AvgStepTime: 0.005ms, MaxStepTime: 69.91ms
Scheduled moves: 129437, completed moves: 129407
Bed compensation in use: mesh
Bed probe heights: -0.136 -0.150 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0, chamberHeaters = -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 1
Stack records: 3 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 doing "G1 X252.132 Y254.041 E0.10519" in state(s) 0
serial is ready with "M122" 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
lcd is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 4581229.00ms; fastest: 0.03ms
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 sensor: ok
ok
Trying to add some debug code to track hiccup issues in another post (https://forum.duet3d.com/topic/8250/hiccups-causing-layer-shifts) and I've noticed that subsequent calls to StepTimer :: GetInterruptClocks is occasionally returning non incrementing values.
I printed the slow loop calculation from reprap.cpp
SlowLoop was wrong 4581228.500000, dt 4294901859, end 355467264, start 355532701
SlowLoop was wrong 4581228.500000, dt 4294901864, end 373620736, start 373686168
SlowLoop was wrong 4581228.500000, dt 4294901859, end 479657984, start 479723421
SlowLoop was wrong 4581228.500000, dt 4294901861, end 507248640, start 507314075
SlowLoop was wrong 4581229.000000, dt 4294901908, end 563609600, start 563674988
On a duet maestro, is that expected?
I wonder if this might be causing my rare hiccups.
Clarification, it happens between 12 to 24 hours of printing, repeating about every 24 hours on ongoing prints.
I've been trying to hunt down the cause of layer shifting on my Duet Maestro CoreXY for the last few weeks, an issue I am very certain is not physical in nature. I've adding tracking marks to my belts, swapped out all motors and cables, ramped down speeds, accel and jerks, etc.
When it does shift is isn't on 45 degrees, and the angles and amount is notably varying, and now I am almost certain it is related to hiccups showing up in the debug logs as I always end up with precisely 1 layer shift per hiccups.
I also don't think this is cause by microstepping, I am not using a particularly aggressive configuration and reducing from 32 - 16 microsteps on E and Z has not really resulted in a change. It typically always shifts between 12hours to 12hours of printing.
I am in the process of compiling firmware from source with hasHiccups triggering a stepping error to try and get more result. In the mean time this is my current config.
M569 P0 S0 D3 F2 V1000 ; Drive 0 goes forwards (A)
M569 P1 S0 D3 F2 V1000 ; Drive 1 goes forwards (B)
M569 P2 S0 D3 F2 V1000 ; Drive 2 goes forwards (ZA)
M569 P3 S1 D3 F2 V1000 ; Drive 3 goes backwards (E0)
M569 P4 S0 D3 F2 V1000 ; Drive 4 goes forwards (ZB)
M584 Z2:4 E3 ; Setup dual Z drives
M906 X1400 Y1400 Z800:800 E800 I50 ; Set motor currents (mA) and motor idle factor in per cent
M350 X16 Y16 Z16 E32 I1 ; Configure microstepping with interpolation
M92 X160 Y160 Z420 E840 ; Set steps per mm
M566 X900 Y900 Z300 E2400 ; Set maximum instantaneous speed changes (mm/min)
M203 X8400 Y8400 Z1200 E2400 ; Set maximum speeds (mm/min)
M201 X1500 Y1500 Z250 E3060 ; Set accelerations (mm/s^2)
M84 S30 ; Set idle timeout
And the M122 output. (Saving a .txt file from the console seems to have fully stripped line endings, the the formatting may be a bit off as I needed to add them back manually)
10:17:25 PM: M122: === Diagnostics ===
RepRapFirmware for Duet 2 Maestro version 2.02RC6(RTOS) running on Duet Maestro 1.0
Board ID: 08DGM-95762-FD3TD-6JTDD-3SW6S-18AZH
Used output buffers: 1 of 20 (20 max)
=== RTOS ===
Static ram: 19476
Dynamic ram: 97400 of which 0 recycled
Exception stack ram used: 380
Never used ram: 13816
Tasks: NETWORK(ready,680) HEAT(blocked,1300) MAIN(running,1892) IDLE(ready,204)
Owned mutexes:
=== Platform ===
Last reset 31:22:14 ago, cause: power up
Last software reset at 2018-12-20 14:54, reason: User, spinning module GCodes, available RAM 13852 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0400f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 4
Free file entries: 9
SD card 0 detected, interface speed: 15.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 38.5, current 39.3, max 40.4
Supply voltage: min 22.6, current 22.9, max 23.1, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: ok, read errors 0, write errors 0, ifcount 28, reads 60883, timeouts 0
Driver 1: ok, read errors 0, write errors 0, ifcount 28, reads 60883, timeouts 0
Driver 2: standstill, read errors 0, write errors 0, ifcount 15, reads 60881, timeouts 2
Driver 3: ok, read errors 0, write errors 0, ifcount 11, reads 60882, timeouts 1
river 4: standstill, read errors 0, write errors 0, ifcount 15, reads 60883, timeouts 0
Driver 5: ok, read errors 0, write errors 0, ifcount 0, reads 0, timeouts 60883
Driver 6: ok, read errors 0, write errors 0, ifcount 0, reads 0, timeouts 60883
Date/time: 2018-12-21 22:17:19Slowest loop: 4581229.00ms; fastest: 0.11ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0
=== Move ===
Hiccups: 1, StepErrors: 0, LaErrors: 0, FreeDm: 150, MinFreeDm: 150, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 2552199, completed moves: 2552169
Bed compensation in use: mesh
Bed probe heights: -0.026 -0.090 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0, chamber
Heaters = -1 -1
Heater 0 is on, I-accum = 0.2
Heater 1 is on, I-accum = 0.4
=== GCodes ===
Segments left: 1
Stack records: 3 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 doing ""G1 X96.581 Y75.131 E0.07115"" 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
lcd is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 4581229.00ms; fastest: 0.03ms
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 sensor: ok
10:17:24 PM: Message Log cleared!
Any insight on what else to check would be greatly appreciated.
It is also possible that this change didn't start happening until 2.02RC3. At one point I reverted from RC3 to RC2 and I don't think I was able to reproduce. I updated again at RC5 (and now RC6) and the problem has returned.
Went over the leads and followed the traces as best as I could, everything checks out. I have two PT1000 so I put them on E0 and E1 channels and set them on the warm heat bed, they seem to track closely at the low temperature.
Since there doesn't seem to be any obvious problems with using it with a lower resistor value I think I'll just keep the board as it is.
Thanks again for your time and response.
@dc42 Already done. I checked all the resistors, they are green(-ish) and look to be marked 220. R15, R19 and R53. Values are very close to 2.2 for all the other resistors except this one (R15) which measures 1.7.
I've been chasing down some issues with my thermistor reporting temperatures that I suspect were really off at high temperatures, switched to a PT1000 and the problem became apparent at 20C. Switched that to the second thermistor channel and it all worked fine.
In the end the pull-up resister on the first thermistor channel reads 1.72k on my multimeter, and when using this value room temperature is spot on for thermistors and PT1000.
Is there any reason why I wouldn't be able to use it using a configuration like:
M305 P1 X501 R1720
Thanks.
@dc42 Thanks for taking a look so quickly.
Since the shifts only happen after 12-24 hours it's been a bit slow to confirm, but in the end it looks like it was caused by a bad cable that otherwise passed a visual inspection of the crimps.
I hope the bug report has helped in other ways at least.
I'm trying to investigate a layer shifting problem that happens only after printing for many hours. In doing this, I've noticed a few consistently reported Look Ahead errors in my log.
I cannot say for certain that these are related, since I receive 2 LaErrors several hours apart, but only 1 layer shift and was not on hand to witness that the error and shift happened at the same time.
None the less, the details follow
=== Diagnostics ===
RepRapFirmware for Duet 2 Maestro version 2.02RC3(RTOS) running on Duet Maestro 1.0
Board ID: 08DGM-95762-FD3TD-6JTDD-3SW6S-18AZH
Used output buffers: 3 of 20 (16 max)
=== RTOS ===
Static ram: 22524
Dynamic ram: 95528 of which 0 recycled
Exception stack ram used: 408
Never used ram: 12612
Tasks: NETWORK(ready,456) HEAT(blocked,1300) MAIN(running,3632)
Owned mutexes:
=== Platform ===
Last reset 16:10:15 ago, cause: software
Last software reset at 2018-11-09 19:20, reason: User, spinning module GCodes, available RAM 12600 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x04418000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 15.0MBytes/sec
SD card longest block write time: 5.0ms, max retries 0
MCU temperature: min 35.7, current 36.0, max 36.8
Supply voltage: min 22.6, current 22.9, max 23.1, under voltage events: 0, over voltage events: 0
Driver 0: standstill, read errors 0, write errors 0, ifcount 54, reads 2535, timeouts 0
Driver 1: standstill, read errors 0, write errors 0, ifcount 54, reads 2535, timeouts 0
Driver 2: standstill, read errors 0, write errors 0, ifcount 54, reads 2535, timeouts 0
Driver 3: standstill, read errors 0, write errors 0, ifcount 40, reads 2526, timeouts 9
Driver 4: standstill, read errors 0, write errors 0, ifcount 54, reads 2534, timeouts 1
Driver 5: ok, read errors 0, write errors 0, ifcount 0, reads 0, timeouts 2536
Driver 6: ok, read errors 0, write errors 0, ifcount 0, reads 0, timeouts 2536
Date/time: 1970-01-01 00:00:00
Slowest loop: 4581229.00ms; fastest: 0.12ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 2, FreeDm: 240, MinFreeDm: 150, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: mesh
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.4
=== GCodes ===
Segments left: 0
Stack records: 2 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
lcd is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 4581229.00ms; fastest: 0.03ms
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 10Mbps full duplex
=== Filament sensors ===
Extruder 0 sensor: ok
And the info from the serial port:
(First error)
DDA.cpp(971) tn=63.789 DDA: start=[145.475998 106.597000 139.229996] end=[123.108002 118.694000 139.229996] s=25.429602 vec=[-0.879605 0.475705 0.000000 0.000000 0.000000]
a=590.270813 d=590.270813 reqv=100.837936 startv=16.817129 topv=100.837936 endv=63.788532 sa=8.373676 sd=5.166537
cks=302827 sstcda=1147363319 tstcddpdsc=85807 exac=7694
(Second error)
DDA.cpp(971) tn=28.953 DDA: start=[210.080994 92.476997 229.830002] end=[210.432007 92.358002 229.830002] s=0.370635 vec=[0.947059 -0.321059 0.000000 0.032903 0.000000]
a=630.855957 d=630.855957 reqv=60.000004 startv=20.305973 topv=29.310781 endv=28.953011 sa=0.354114 sd=0.016521
cks=13913 sstcda=1146301974 tstcddpdsc=71917 exac=22
DDA.cpp(971) tn=7.454 DDA: start=[139.722000 165.498993 246.629990] end=[138.919006 165.173004 246.629990] s=0.866642 vec=[-0.926558 -0.376152 0.000000 0.033772 0.000000]
a=614.104492 d=614.104492 reqv=60.000004 startv=27.890314 topv=30.804615 endv=7.454000 sa=0.139272 sd=0.727370
cks=40096 sstcda=1146608198 tstcddpdsc=63662 exac=0
Should I be concerned about these errors?