New Duet WiFi firmware 1.19beta1
-
M552 with no params reports the IP address
-
M552 with no params reports the name of the access point I am connected to on the Panel Due display, but does not report the ip unfortunately.
-
ah it does on the DWC stby and I'll just check it on mine
-
M552 on my PanelDUE does give me the IP Address
it reports the configured IP address (This is ignored of course) and the Actual IP address -
So. I tried the update to the beta again. It did connect this time and gave me an ajax error a few seconds later. This is what it said.
Communication Error
An AJAX error has been reported, so the current session has been terminated.
Please check if your printer is still on and try to connect again.
Error reason: SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data
And here is the output from M122.
M122
SENDING:M122
=== Diagnostics ===
Used output buffers: 1 of 32 (7 max)
=== Platform ===
Static ram used: 20356
Dynamic ram used: 95748
Recycled dynamic ram: 2680
Stack ram used: 3680 current, 4504 maximum
Never used ram: 7784
Last reset 00:05:03 ago, cause: power up
Last software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff
Spinning module during software reset: GCodes, available RAM 32812 bytes (slot 0)
Error status: 0
[ERROR] Error status: 0Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 17.9, current 23.5, max 26.8
Supply voltage: min 12.1, current 12.2, max 12.4, under voltage events: 0, over voltage events: 0
Driver 0: standstill
Driver 1: standstill
Driver 2: standstill
Driver 3: standstill
Driver 4: standstill
Date/time: 2017-05-22 17:39:21
Slowest main loop (seconds): 0.013398; fastest: 0.000036
=== Move ===
MaxReps: 0, StepErrors: 0, 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
Probe change coordinates:
=== Heat ===
Bed heater = 0, chamber heater = -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 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
Code queue is empty.
Network state is running
WiFi module is connected to access point
WiFi firmware version 1.19-beta1
WiFi MAC address a0:20:a6:16:ea:67
WiFi Vcc 3.06, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 40344
WiFi IP address 192.168.1.10
WiFi signal strength -38db
HTTP sessions: 1 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)Plus when I hooked up to it via usb, only the extruder would and heaters would operate. It would not home any of the axis'.
I have rolled it back to 1.18.1 again and the wifi won't connect but it operates normally via usb.This has the same software reset code as I have
-
I didn't think you could set a static IP in the config with a duetwifi. David had told me that awhile back. Has that changed?
-
Static IP should be set it in your wireless router using the Duet Wifi's MAC address.
-
In 1.19 you can set up a static IP address in the connection parameters you give in the M587 command. See https://duet3d.com/wiki/G-code#M587:_Add_WiFi_host_network_to_remembered_list.2C_or_list_remembered_networks.
-
Is there a beta for the Ethernet board? I am on 1.19alpha and I am unable to get mesh leveling to work. It will probe the bed and even save the height map file. It is non compensating for my bed at all during the print and M122 says "Bed compensation in use: none". This is right after running G29 or G29 S1
-
I'm not sure I want to upgrade to 1.19. The web-server works OK for me.
Can I just upgrade DWC to 1.16?
-
I think DWC 1.16 should work with firmware 1.18 but I haven't tested it.
There will be a new 1.19beta1 tomorrow or possibly later today. However, the changes in 1.19 are mostly to do with WiFi improvements and supporting new kinematics, do Duet Ethernet and users of older Duets are probably better off staying with 1.18.1 for now.
-
I think the switching method is a bit cumbersome. Besides, I suspect that running the web-server in ESP is better for stable printing, there won't be any lags when the web-interface is updated. I vaguely remember that the printer used to freeze for a moment when I connected to duet 0.8.5.
-
I had a new crash today mid print on a small item. This is not the same code as last time.
Here is the M122 output.
1:57:59 PMM122
=== Diagnostics ===
Used output buffers: 3 of 32 (6 max)
=== Platform ===
Static ram used: 20356
Dynamic ram used: 95740
Recycled dynamic ram: 2688
Stack ram used: 1296 current, 3592 maximum
Never used ram: 8696
Last reset 00:00:33 ago, cause: software
Last software reset code 0x4031, HFSR 0x40000000, CFSR 0x00008200, ICSR 0x00427803, BFAR 0x8b24b30e, SP 0x2001fe3c
Stack: 0041a35f 00435340 21000000 400c0000 00000001 2001fee8 0041a471 0042b1a0 81000000 000003f8 ffffffe9 930db660 3f8ffd08 35793c76 3e1a39ef fffffc1e 00430351 00433746
Spinning module during software reset: Network, available RAM 3560 bytes (slot 2)
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 35.0, current 37.1, max 40.5
Supply voltage: min 24.2, current 24.3, max 24.5, under voltage events: 0, over voltage events: 0
Driver 0: standstill
Driver 1: stalled standstill
Driver 2: standstill
Driver 3: stalled standstill
Driver 4: standstill
Date/time: 2017-05-25 13:57:58
Slowest main loop (seconds): 0.013393; fastest: 0.000034
=== Move ===
MaxReps: 0, StepErrors: 0, 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
Probe change coordinates:
=== Heat ===
Bed heater = 0, chamber heater = -1
Heater 1 is on, I-accum = 0.0
=== 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
Code queue is empty.
Network state is running
WiFi module is connected to access point
WiFi firmware version 1.19-beta1
WiFi MAC address 5c:cf:7f:2b:ec:d5
WiFi Vcc 3.09, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 40080
WiFi IP address 10.0.1.14
WiFi signal strength -74db
HTTP sessions: 1 of 8
Socket states: 2 0 0 0 0 0 0 0
Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)And version info:
Firmware Name: RepRapFirmware for Duet WiFi
Firmware Electronics: Duet WiFi 1.0
Firmware Version: 1.19beta1 (2017-05-21)
WiFi Server Version: 1.19-beta1
Web Interface Version: 1.16 -
@pkm:
I think the switching method is a bit cumbersome. Besides, I suspect that running the web-server in ESP is better for stable printing, there won't be any lags when the web-interface is updated. I vaguely remember that the printer used to freeze for a moment when I connected to duet 0.8.5.
The setup mechanism is a little cumbersome right now, but the switching mechanism is automatic - it connects to the strongest network it can find that you have configured it to recognise.
The web server on the ESP was problematic. It was based on modified Arduino code for the ESP8266, some of which was of poor quality, and in some network environments it crashed repeatedly. Ths SDK for the ESP8266 is not open source. Overall, debugging and maintaining the ESP8266 code was a nightmare. That is why we decided to simplify it by moving the HTTP server off the ESP and on to the SAM. This also means that we are using the same architecture on the Duet WiFi as on the Duet Ethernet, so there is less code to maintain overall.
I think you will find that these days, even on the Duet085 you can connect a new web client without the print pausing.
-
Thanks David.
By "switching" I meant switching from older firmware to 1.19. I wish it was simpler.Could you make some ALL-IN-ONE firmware file to update everything at once?
-
Had a new crash today. This time inbetween prints so no ruined print. I had the printer printing for 2hours or so and then it was resting on for 3-4hours. When I came back and accessed the web interface it heard the fan spin up like it does when it boots and I got ajax error. This happened a few times and it was not possible to access the printer before I cycled power to it then it let me connect. Here is the M122 output. Looks like the software reset code is different this time so I'm posting it again.
[[language]] === Diagnostics === Used output buffers: 3 of 32 (5 max) === Platform === Static ram used: 20356 Dynamic ram used: 95764 Recycled dynamic ram: 2664 Stack ram used: 1296 current, 5872 maximum Never used ram: 6416 Last reset 00:02:14 ago, cause: software Last software reset code 0x5001, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0440f80f, BFAR 0xe000ed38, SP 0xffffffff Spinning module during software reset: Network, available RAM 8696 bytes (slot 0) Error status: 0 Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest block write time: 170.1ms MCU temperature: min 32.3, current 35.5, max 38.4 Supply voltage: min 23.7, current 23.8, max 24.6, under voltage events: 0, over voltage events: 0 Driver 0: stalled standstill Driver 1: stalled standstill Driver 2: stalled standstill Driver 3: standstill Driver 4: standstill Date/time: 2017-05-27 16:41:01 Slowest main loop (seconds): 0.171326; fastest: 0.000034 === Move === MaxReps: 2, StepErrors: 0, MaxWait: 20932ms, Underruns: 0, 0 Scheduled moves: 8, completed moves: 8 Bed compensation in use: none Bed probe heights: 0.000 0.000 0.000 0.000 0.000 Probe change coordinates: === Heat === Bed heater = 0, chamber heater = -1 Heater 0 is on, I-accum = 0.0 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 Code queue is empty. Network state is running WiFi module is connected to access point WiFi firmware version 1.19-beta1 WiFi MAC address 5c:cf:7f:2b:ec:d5 WiFi Vcc 3.09, reset reason Turned on by main processor WiFi flash size 4194304, free heap 40056 WiFi IP address 10.0.1.14 WiFi signal strength -71db HTTP sessions: 1 of 8 Socket states: 2 0 0 0 0 0 0 0 Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) -
I updated to 1.19beta1 (2017-05-21) FW and Wifi server with 1.16 web interface today and I'm starting to find that the Duet Wifi board is now randomly resetting itself. The first time was in the middle of a small print and then not long after trying to start it again. It would be an incredible coincidence if my PSU is starting to pack it in directly after updating the FW?
I've always found that the 12V fans dip in speed as soon as either/both the heat bead/hot end are heating but that has never caused the board to reset in the past. The PSU is from a PC and is rated at 700W.
Just trying the small print job again to see if it can make it through without a reset….
Unfortunately, it reset mid job again. More of a crash considering I cannot get a wifi connection after that point and pressing the reset button fails to get the wifi back. I have to completely power down the PSU via the mains switch to get it working again. My biggest concern is that the 12V supply shuts off as well when it crashes which leaves the E3D heatsink without a fan and a hot end sitting at 240 deg. So I have to move quickly before the new Aero heatsink gets too hot for the plastic parts touching it.
Going to roll back to 1.18 now to see if the crash is unrelated to the PSU...
-
Firmware 1.19beta1 is now superseded by 1.19beta2. Those of you who were having problems with beta1 please try beta2.
