New beta firmware 1.20beta7

StevenL

At the risk of being repeated, What are the proper commands to upgrade the Duetwifi firmware?
Duetwifi Server upgrade?
any other upgrades?

deckingman

@StevenL:

At the risk of being repeated, What are the proper commands to upgrade the Duetwifi firmware?
Duetwifi Server upgrade?
any other upgrades?

It's all documented in the Wiki https://www.duet3d.com/wiki. Scroll down about half way to find the firmware updating instructions.

idaho creator

DC42

I have noticed and thought it was only an issue in 1.20beta3 but have now had it occur in 1.20beta7. I have only come across this because I upgraded to dual e3d v6 extruders. I have noticed if a fault on heater 1 occurs I can use m562 p1 to reset it without restarting the printer. As long as I am not in the middle of a print. Once the printer goes though bed leveling and then on to printing. If I induce a fault, the printer pauses print right where it is and marks extruder as fault. I am though unable to use M562 command, any command therefor, and emergency stop doesn't reboot Duetwifi. I then need to kill the power to the printer to get it to respond to web server commands. I don't have a Paneldue that is the next upgrade so I don't know if that is possible.

dc42

Thanks for that report. I'll test it before I release beta 8. Please check using M115 that you really are running beta 7.

idaho creator

Below is the m115 report.

M115
FIRMWARE_NAME: RepRapFirmware for Duet WiFi FIRMWARE_VERSION: 1.20beta7 ELECTRONICS: Duet WiFi 1.0 FIRMWARE_DATE: 2017-11-11

mchiriciuc

Hi.
I'm trying to use Z baby stepping in 1.20beta7 and it seems that the offset is not stored and applied to further moves.
To test this I have set up Z home with a 2mm offset so the print will stat clearly in the air and then tryied to compensate it with M290 S-2 command. It lowered the Z axis by 2mm as expected for one segment then came back to the same height it was before the M290 command.
Is there something I'm missing?

dc42

The offset will be lost when you power down the printer, or you home Z, or you probe the bed. Otherwise it should be preserved.

Babystepping is intended for small corrections, so the M290 command is limited to +/- 1mm.

zlowred

I never noticed that before, but with the latest (1.20beta7) firmware I just had 3 occurrences of what looks like the firmware hanging and then being reset by the watchdog. This seem to be random and not reproducible (happened on different gcode files, and then I'm able to print the same file without any problems).
The symptoms are printer just stops mid-print after an hour or two of printing, and several seconds later the 24v power shuts down (I use separate standby 5v power supply) - I believe that's firmware restarting because of the watchdog.
Here is the output of M122 when I connected by USB after such failure:

=== Diagnostics ===
Used output buffers: 1 of 32 (1 max)
=== Platform ===
RepRapFirmware for Duet WiFi version 1.20beta7 running on Duet WiFi 1.0
Board ID: 08DDM-9FAM2-LW4S8-6JTDD-3SJ6P-9MXBY
Static ram used: 15472
Dynamic ram used: 99144
Recycled dynamic ram: 72
Stack ram used: 3992 current, 5012 maximum
Never used ram: 11372
Last reset 00:01:15 ago, cause: reset button or watchdog
Last software reset reason: User, spinning module GCodes, available RAM 11568 bytes (slot 3)
Software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 31.6, current 35.5, max 35.7
Supply voltage: min 0.4, current 0.5, max 24.3, under voltage events: 1, over voltage events: 0
Driver 0: standstill
Driver 1: standstill
Driver 2: standstill
Driver 3: standstill
Driver 4: standstill
Date/time: 1970-01-01 00:00:00
Cache data hit count 259223121
Slowest main loop (seconds): 0.001733; fastest: 0.000033
=== Move ===
MaxReps: 0, StepErrors: 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 heater = 0, chamber heater = -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 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
autopause is idle in state(s) 0
Code queue is empty.
Network state is running
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.20b8
WiFi MAC address _WiFi Vcc 3.35, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 28824
WiFi IP address 192.168.1.102
WiFi signal strength -53dBm, reconnections 0, sleep mode modem
HTTP sessions: 0 of 8
Socket states:  0 0 0 0 0 0 0 0
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)_

DjDemonD

@dc42:

No, I don't think it's order-related. Try uploading wifiserver b8 again. If it gets stuck in "starting up" again, send M997 S1 again to reinstall the same file and see if that fixes it.

Uploaded wifiserver b8 after uploading 1.20 b7 firmware, and working normally. This was on a v1.00 duet wifi. My other machine with a v.102 duetwifi upgraded without a problem.

zlowred

The issue described in https://www.duet3d.com/forum/thread.php?pid=30376#p30376 still happens after the upgrade to 1.20beta8

dc42

Thanks for your report. It does look like a watchdog reset. Prior to installing 1.20b7, what was the last firmware version you used that you are confident did not have this problem?

zlowred

Last version I'm pretty sure was stable is the one I built myself, immediately after I added the 3-wire PT100 support. I've spent maybe 20 hours printing on that version, and didn't see any resets. The next one (was that 1.20beta6?) also never reset, but I spent only couple of hours printing with it, so less confident.

zlowred

I wonder if this is related to the WiFi disconnections. I've looked at the assertion that produces that p->ref==1 message. If that indicates any sort of memory corruption, the watchdog reset could happen irrespective to your recent changes in the code. It might be that because of totally unrelated changes the compiler optimised something slightly differently, and it started to cause side-effects that weren't there before.