New beta firmware 1.20beta7

  • administrators

    I've just released this in the usual Edge folders. See as usual for the change list and upgrade notes.

  • Okay so I downloaded, duetwifiserver-1.20b8,bin and sent it via DWC and installed it, whilst running 1.20 beta 6 firmware. When it restarted I had no working wifi connection to the printer, when I send M552 from paneldue, I get "wifi module is starting up" but thats as far as it gets.

    So I used the sd card method to install 1.20 beta7 figuring maybe it was a firmware to wifiserver mismatch, but despite installing successfully its the same problem.

    How do I install wifiserver (going back to beta 2 which I was using before) without access to DWC? Can I do it from SD card/paneldue?

  • Okay so I found you can use sd card method using M997 S1 with duetwifiserver.bin renamed file in /sys on mem card and it will install it from paneldue.

    Done and now working again.

    I haven't had an issue with any firmware update for ages.

  • administrators

    You are not the only person to have had to install the new DuetWiFiServer.bin file twice. I think it's because there have been major changes to the WiFi module SDK requiring reinitialisation of some memory that is not loaded from the file, and it doesn't get initialised with the correct new data the first time.

  • So is it just that I installed it in the wrong order? Now that I have downgraded wifiserver, but have installed B7 main firmware, I can reupload wifiserver b8?

  • administrators

    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.

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

  • @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 Scroll down about half way to find the firmware updating instructions.

  • 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.

  • administrators

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

  • Below is the m115 report.

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

  • 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?

  • administrators

    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.

  • 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
    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)_ 

  • @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.

  • The issue described in still happens after the upgrade to 1.20beta8

  • administrators

    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?

  • 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.

  • 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.

Log in to reply