Unstable after firmware upgrade

demigh0d

DuetWifi 1.03
Duex5 0.7

Upgraded from 1.20beta6

Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.02 or later
Firmware Version: 2.01(RTOS) (2018-07-26b2)
WiFi Server Version: 1.21
Web Interface Version: 1.21.2-dc42

Now I often get communications errors and the ui disconnects. It takes a minute or more before it will connect again. A continuous ping doesn't indicate any dropped packets and my AP doesn't show any drops in the wifi connection.

.

demigh0d

It's also not seeing the Duex5 at times...

=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.01(RTOS) running on Duet WiFi 1.02 or later
Board ID: 08DGM-95BNL-MGPSN-6J1F6-3S86J-T0XRX
Used output buffers: 1 of 20 (11 max)
=== RTOS ===
Static ram: 28476
Dynamic ram: 96704 of which 36 recycled
Exception stack ram used: 320
Never used ram: 5536
Tasks: NETWORK(ready,328) HEAT(blocked,1248) MAIN(running,3540)
Owned mutexes:
=== Platform ===
Last reset 00:05:03 ago, cause: software
Last software reset at 2018-07-31 18:04, reason: Unknown, spinning module Platform, available RAM 5188 bytes (slot 2)
Software reset code 0x00b0 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x200054ac Task 0x4e49414d
Stack: 00445809 0043a80a 2100f000 00000000 00000000 3edb6db7 b7b4d800 3e178897 3e1cd04f 41700000 3e3a4134 3e639cb6 3e9251c9 3c9bf4f7 00000000 00000000 00000000 00000000 00000000 80000010 0043a809 20002bb0 0043ab1b
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 27.0, current 28.0, max 28.1
Supply voltage: min 13.8, current 13.9, max 14.1, under voltage events: 0, over voltage events: 0
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
Date/time: 2018-07-31 18:09:16
Slowest loop: 6.09ms; fastest: 0.08ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 1 is on, I-accum = 0.0
=== 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
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 165.58ms; fastest: 0.08ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8

WiFi -
Network state is running
WiFi module is connected to access point
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.21
WiFi MAC address 68:c6:3a:d6:11:21
WiFi Vcc 3.38, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 14464
WiFi IP address 10.1.20.92
WiFi signal strength -41dBm, reconnections 0, sleep mode modem
Socket states: 0 0 0 0 0 0 0 0
=== Expansion ===

demigh0d

The only other error I get is:

Error: Can't open 0:/sys/oem.json to read, error code 4

Debugging doesn't indicate any problems. I tried unplugging the Duex and the problem persists.

dc42

@demigh0d said in Unstable after firmware upgrade:

The only other error I get is:

Error: Can't open 0:/sys/oem.json to read, error code 4

That error is normal because that file is only used by some of our OEMs, so it is usually not present.
The issue with the Duet not detecting a DueX5 at power up has been reported in older firmware versions too. I increased the retry count in the latest version. I'll look at this area again for the next release.
Which version of DuetWiFiServer were you running with firmware 1.20beta6? Have you tried increasing the max retries in DWC? Chrishamm says he has improved the retry mechanism in his latest DWC (1.22beta3) so you may with to try that.

HTH David

demigh0d

@dc42

I upgraded DWC to 1.22b3 and it looks like that took care of the disconnects.

I don't recall what version DuetWiFiServer. This was a new board and as soon as I verified it was working ok I upgraded the firmware. This is my 3rd Duet (2nd Duex) so it's not the first time I've upgraded Duet firmware.

DWC retries are set at 5.

A couple other thing I notice since upgrading. When I try moving the head via the paneldue it takes ~20 seconds from the time I press the button until the printer responds. From the DWC there's ~5 seconds delay.

And when I tell it to home it often only moves part way and then stops. I have to home 2-3 times before it actually completes the homing. It's configured for sensorless homing at 50% current.

demigh0d

The Duex isn't detected when coming back from a reset (stop, reset button, or reset after config upgate. It takes a powercycle to bring it back.

dc42

@demigh0d said in Unstable after firmware upgrade:

The Duex isn't detected when coming back from a reset (stop, reset button, or reset after config upgate. It takes a powercycle to bring it back.

Thanks for the update. This has been reported before, but I haven't yet been able to reproduce it. I'll try some more.

demigh0d

It appears that, at least some of my, problems may have been attributable to the sd card that came with the DuetWifi.

In trying to install the latest firmware, and failing, I discovered a bunch of corrupt directory entries on the sd card. It continued to give me problems even after a full format so I have replaced it.

dc42

I still haven't been able to reproduce the DueX not being recognised after a software reset. However, in the latest 2.02beta1 firmware I made a change that may help.

samlogan87

I have this same issue. I upgraded to 2.01 tonight and my due2 is not always found causing the extruder stepper not to run and the fans I have running off the board to run full speed. It also causes the bl touch to play up. I think it is also causing my printer to not print properly. I was printing a calibration cube tonight and it would print normally for a bit and then slow down . It would do one line of the infill and then wait 3-5seconds before it did the next. I might look at going back to 1.21

T3P3Tony

@samlogan87 what do the i2c errors look like in the M122 report.

samlogan87

Hi @T3P3Tony

Please see below.

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.01(RTOS) running on Duet Ethernet 1.02 or later
Board ID: 08DGM-956GU-DJMSN-6J9D4-3SD6Q-1VR7G
Used output buffers: 3 of 20 (6 max)
=== RTOS ===
Static ram: 28476
Dynamic ram: 95948 of which 0 recycled
Exception stack ram used: 284
Never used ram: 6364
Tasks: NETWORK(ready,464) HEAT(blocked,1216) MAIN(running,3476)
Owned mutexes:
=== Platform ===
Last reset 00:00:12 ago, cause: software
Last software reset time unknown, reason: User, spinning module GCodes, available RAM 6408 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 6.8ms, max retries 0
MCU temperature: min 16.4, current 17.3, max 17.5
Supply voltage: min 24.1, current 24.2, max 24.4, under voltage events: 0, over voltage events: 0
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
Date/time: 2018-08-24 06:52:59
Slowest loop: 9.84ms; fastest: 0.07ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 1 -1 -1 -1, chamberHeaters = -1 -1
=== 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: 14.66ms; 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
=== Expansion ===

Kind Regards,
Sam Logan

T3P3Tony

@samlogan87 Ahn I think the I2C errors was only reported in 2.02 beta 2 - can you try that please

samlogan87

@T3P3Tony ok will do this morning. I am also having issues where sometimes it prints really slow and even moves off the web Control slowly. It’s like it is buffering between some moves. It works fine for a bit then does it. It is with g code files that did work before the upgrade