It pretty much matches my experience, much better though not perfect. I have also ruled out the temperature, yesterday I had the printer on (but not printing) for most of the day, and I could not connect.
I think the first disconnection was triggered by me trying to FTP two files simultaneously: after that, it was a no-go for any complex connection till a physical reboot. Calling the rr_status API endpoint always succeeds, though, as pinging the board.
@Foden, I hear you; my network is also extremely stable. I have a professional Ubiquiti setup, and the Duet is on a restricted network with less than 10 devices. It is also quite close to the switch, so the Ethernet cable is not long.
Anyway, reading the forum, I have found a couple of posts where @dc42 mentioned the added computing power required to deal with small cluster sizes on the SD card. So, I have reformatted my card using 64KB as cluster size. I did this yesterday, and the printer was on all day with no disconnections.
I also thought it might depend on the temperature, and yesterday it was PLA, but today I'm printing ABS with the bed at 100ºC and an enclosed chamber, and it's been very stable.
I'll post an update here if things go south again, but increasing the cluster size is definitely something I'd recommend everyone to do.
Hi all. I've been using this for quite some time and it has always been very reliable. Unfortunately, the API response format has changed (I noticed this in RRF v3.2beta4). I have fixed the problem, but I don't have the time right now to make it generic and support both the old and new versions of the firmware.
@Torin I have submitted a merge request.
If anyone has this problem, you can get my fork.
I agree, and I would add that it might be something related to our network configuration, or more people would be raising it.
I am not sure if this is helpful in any way, but I have noticed that the connection is usually reliable for a while, right after switching the board on. Then, it degrades progressively, and after some time, it's hard to do anything.
Also, on the status page during a print, often the web interface keeps trying to reconnect. Still, I can see data updating behind the overlay: is the JS code too aggressive to detect disconnections? I have set the number of AJAX retries to 4 and the update interval to 500ms.
@bearer said in Constant 'connection interrupted':
it'd be interesting to see the wireshark log; if its a common issue it needs to be in RRF and not in the Wifi Firmware (separate fimwares) .. but it could also be different issue but same symptoms however unlikely it may be.
It looks very similar to the screenshots @Foden sent earlier. Here is the WS capture: https://www.dropbox.com/t/tIMSR7APIe63zAsL
113 is the Duet, 25 is my laptop
Hi all,
I see the same problem on a wired connection (Duet 2 Maestro, static IP, connected to my main switch). I have, of course, tried different cables, so this is not the issue.
I saw this problem on 2.05 (possibly on 2.04 though I don't remember); now I am on 3.2beta4, and it keeps happening. I could not find any triggering factor; sometimes, everything works fine for hours, while other times I can't keep a stable connection for more than 10 seconds. When the HTTP connection is not responsive, the same happens to FTP, but I can still ping the board with no losses and normal ping times.
My network is very stable, and the printer is on a subnet with very few devices.
I can run Wireshark as well if helpful, but I wanted to point out that the issue is not limited to WiFi.
I can live with this issue (I have for quite a while), but it is annoying, so if there's a solution I'd gladly take it!
M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 Maestro FIRMWARE_VERSION: 3.2-beta4 ELECTRONICS: Duet Maestro 1.0 FIRMWARE_DATE: 2020-11-26
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 Maestro version 3.2-beta4 running on Duet Maestro 1.0
Board ID: 08DJM-956DU-LL3T0-6JTD8-3S86Q-1U2AP
Used output buffers: 1 of 24 (24 max)
=== RTOS ===
Static ram: 22980
Dynamic ram: 91876 of which 60 recycled
Never used RAM 15132, free system stack 144 words
Tasks: NETWORK(ready,201) HEAT(blocked,329) TMC(blocked,113) MAIN(running,404) IDLE(ready,21)
Owned mutexes:
=== Platform ===
Last reset 01:18:57 ago, cause: software
Last software reset at 2020-12-01 11:28, reason: User, GCodes spinning, available RAM 15132, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN
Error status: 0x04
MCU temperature: min 55.3, current 59.3, max 59.9
Supply voltage: min 23.3, current 24.0, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: position 8094, standstill, read errors 0, write errors 0, ifcnt 48, reads 17804, writes 0, timeouts 0, DMA errors 0
Driver 1: position 10545, ok, read errors 0, write errors 0, ifcnt 47, reads 17804, writes 0, timeouts 0, DMA errors 0
Driver 2: position 3385, ok, read errors 0, write errors 0, ifcnt 48, reads 17804, writes 0, timeouts 0, DMA errors 0
Driver 3: position 0, ok, read errors 0, write errors 0, ifcnt 40, reads 17804, writes 0, timeouts 0, DMA errors 0
Driver 4: position 0, ok, read errors 0, write errors 0, ifcnt 48, reads 17803, writes 0, timeouts 0, DMA errors 0
Driver 5: position 0, assumed not present
Driver 6: position 0, assumed not present
Date/time: 2020-12-01 12:47:55
Slowest loop: 14.37ms; fastest: 0.10ms
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: 15.0MBytes/sec
SD card longest read time 2.0ms, write time 4.1ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 166, MinFreeDm: 151, MaxWait: 0ms
Bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 11733, completed moves 11728, StepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state 3
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, StepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.6
Heater 1 is on, I-accum = 0.5
=== 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 X100.690 Y105.428 E1.0722" 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 48.65ms; fastest: 0.03ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
Interface state active, link 100Mbps full duplex
=== Filament sensors ===
Extruder 0: pos 91.41, errs: frame 16 parity 0 ovrun 0 pol 14 ovdue 0
Hi, a quick update from me. Duet replaced my sensor (kudos to @Roland, the swap was quick and flawless, even if I live in Singapore).
I have been using the new sensor for several weeks now, and it has saved many prints, and potentially more disastrous situations. The sensor never paused the printer without a valid reason: clogged nozzle, empty spool, and once the spool even fell to the floor.
Great tool, highly recommended.
@dc42 Thank you, I'll wait for further instructions.
I did some more prints, unfortunately the results have been consistently not good; I thought it might be noise, so I have changed the cable to a quality shielded one yesterday, but the issue remains. I get negative low ends of the range very quickly after starting a print. Here is the M122 output after a long print, with the shielded cable:
10/22/2019, 7:22:19 AM M122
=== Diagnostics ===
RepRapFirmware for Duet 2 Maestro version 2.04RC3 running on Duet Maestro 1.0
Board ID: 08DJM-956DU-LL3T0-6JTD8-3S86Q-1U2AP
Used output buffers: 3 of 24 (17 max)
=== RTOS ===
Static ram: 19796
Dynamic ram: 93912 of which 0 recycled
Exception stack ram used: 396
Never used ram: 16968
Tasks: NETWORK(ready,652) HEAT(blocked,1272) MAIN(running,3904) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 09:35:17 ago, cause: power up
Last software reset at 2019-10-13 14:43, reason: User, spinning module GCodes, available RAM 17152 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0400f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
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 47.9, current 49.0, max 49.7
Supply voltage: min 23.6, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: ok, read errors 0, write errors 0, ifcount 12, reads 9425, timeouts 0
Driver 1: ok, read errors 0, write errors 0, ifcount 12, reads 9425, timeouts 0
Driver 2: ok, read errors 0, write errors 0, ifcount 12, reads 9425, timeouts 0
Driver 3: ok, read errors 0, write errors 0, ifcount 12, reads 9420, timeouts 5
Driver 4: standstill, read errors 0, write errors 0, ifcount 6, reads 9425, timeouts 0
Driver 5: ok, read errors 0, write errors 0, ifcount 0, reads 0, timeouts 9425
Driver 6: ok, read errors 0, write errors 0, ifcount 0, reads 0, timeouts 9425
Date/time: 2019-10-22 07:22:17
Slowest loop: 70.00ms; fastest: 0.08ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 152, MinFreeDm: 143, MaxWait: 0ms
Bed compensation in use: mesh, comp offset 0.000
=== DDARing ===
Scheduled moves: 132126, completed moves: 132118, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.5
=== GCodes ===
Segments left: 1
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 doing "G1 X50.263 Y165.759 E0.2155" 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: 5.89ms; fastest: 0.03ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 2 of 8
Interface state 5, link 100Mbps full duplex
=== Filament sensors ===
Extruder 0: pos 39.38, ok, measured sens 25.46mm/rev min -1% max 107% over 36407.4mm, errs: frame 148 parity 0 ovrun 0 pol 37 ovdue 0
@themelle Do you have any idea of what the problem might be? The print quality is good and I am using a decent filament (eSun PLA+).
Thank you for getting back to me so quickly. Yesterday night I did a couple of test prints, and for the first time since I installed it, the sensor worked flawlessly. I used a different color of filament, but the material and brand were the same, so I doubt that's the reason. Also, for this sensor, the filament should be irrelevant, unless it's slippery of course.
Here is the full M122 output, there are a couple of errors, but the range is ideal. I will probably replace the wire from the Duet to the sensor with a shielded one and keep monitoring the output; hopefully, the issues were just transient.
14/10/2019, 22:35:07 M122
=== Diagnostics ===
RepRapFirmware for Duet 2 Maestro version 2.04RC3 running on Duet Maestro 1.0
Board ID: 08DJM-956DU-LL3T0-6JTD8-3S86Q-1U2AP
Used output buffers: 3 of 24 (15 max)
=== RTOS ===
Static ram: 19796
Dynamic ram: 93912 of which 0 recycled
Exception stack ram used: 392
Never used ram: 16972
Tasks: NETWORK(ready,652) HEAT(blocked,1272) MAIN(running,3904) IDLE(ready,160)
Owned mutexes:
=== Platform ===
Last reset 01:43:23 ago, cause: power up
Last software reset at 2019-10-13 14:43, reason: User, spinning module GCodes, available RAM 17152 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0400f000 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: 81.2ms, max retries 0
MCU temperature: min 40.3, current 47.6, max 50.3
Supply voltage: min 23.6, current 24.1, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, read errors 0, write errors 0, ifcount 9, reads 36374, timeouts 0
Driver 1: standstill, read errors 0, write errors 0, ifcount 9, reads 36374, timeouts 0
Driver 2: standstill, read errors 0, write errors 0, ifcount 9, reads 36374, timeouts 0
Driver 3: standstill, read errors 0, write errors 0, ifcount 9, reads 36371, timeouts 3
Driver 4: standstill, read errors 0, write errors 0, ifcount 6, reads 36377, timeouts 0
Driver 5: ok, read errors 0, write errors 0, ifcount 0, reads 0, timeouts 36378
Driver 6: ok, read errors 0, write errors 0, ifcount 0, reads 0, timeouts 36377
Date/time: 2019-10-14 22:35:06
Slowest loop: 169.18ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0, FreeDm: 160, MinFreeDm: 112, MaxWait: 672759ms
Bed compensation in use: mesh, comp offset 0.000
=== DDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.5
=== 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: 86.83ms; fastest: 0.03ms
Responder states: HTTP(1) 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 197.23, ok, measured sens 25.18mm/rev min 96% max 105% over 5199.2mm, errs: frame 6 parity 0 ovrun 0 pol 8 ovdue 0
Hi, I received the Rotating Magnet filament monitor a couple of days ago (ordered directly from Duet). I have connected it to my Duet Maestro and calibrated it, but the range is too wide to be useful at the moment. I have tried to update the firmware from 2.03 to 2.04RC3, but the behavior is the same.
The following is an example of output during my last print:
M591 D0
Duet3D rotating magnet filament monitor v2 on input 3, disabled, sensitivity 25.58mm/rev, allow 70% to 130%, check every 3.0mm, current pos 117.8, measured sensitivity 25.73mm/rev, min -1% max 106% over 6073.4mm
The sensor is very close to the extruder and attached firmly to the printer frame; I would exclude that as an issue. The next step would be to try a shielded cable, though I doubt there is much interference since the cable is not running close to anything else.
I spent quite some time trying to make the Laser Sensor work (direct reading, with ball bearings, close, far, etc.) before I gave up, hoping this sensor would behave better; unfortunately, the results are worse.
Has anybody had similar problems and managed to make the sensor work?
Thank you in advance for any help.
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 Maestro version 2.04RC3 running on Duet Maestro 1.0
@brunofporto Apologies for the long silence, it took me a while to get to some good results. I have now managed to print for a couple of days with consistent results and no sudden pauses. The sensor also saved a big part that I was printing (no more filament).
The cause of my problems was the filament sliding on the bearing, and this caused negative reads. I have found this product at a local shop, sprayed two layers on my bearings, and the sensor seems now stable, even at high speed. I have also increased the pressure a bit and reprinted the mount with black eSun PLA+, which appears to be stronger than regular PLA.
This is the model that I am currently using. I was too lazy to remodel the attachment to the extruder, which I had already designed in Fusion 360: this is the STL imported by the OpenSCAD file.
These are the bearings.
@crash69 Thank you for this; I really like your design (it printed like a charm)! Also, your .scad file is straightforward to tweak. I have changed the following:
I did a quick test with a shorter sensor distance; the results were much better than with direct reading, but I still got a wide range. In the next few days, I will print another one with all the changes listed above. If anybody is interested, I can publish the remix.
Thank you all for this very informative thread.