Unstable after firmware upgrade

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