It's out! RepRapFirmware 2.0 and 1.21.1 released
-
I've been busy with EMC compatibility testing for CE certification for the last 2 days, so I've had very little time to respond to forum questions. In answer to your question, we hope to support updating PanelDue version 3.0 controllers through the Duet in the future, however we need to write some firmware to make that possible. So at present you have to update them through USB.
-
Hi, I just have a serious layer shift on some pieces. The printer was running for many days non stop without a single issue.
Mechanically everything moves smoothly.
Here's my M122. After that, I restart the print, and so far everithing is going well.M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS) running on Duet Ethernet 1.02 or later
Board ID: 08DGM-95BNL-MGPSJ-6J1FJ-3S86T-12ZMW
Used output buffers: 4 of 20 (12 max)
=== RTOS ===
Static ram: 28380
Dynamic ram: 95468 of which 16 recycled
Exception stack ram used: 572
Never used ram: 6636
Task NETWORK ready, free stack 324
Task HEAT blocked, free stack 800
Task MAIN running, free stack 3588
=== Platform ===
Last reset 100:27:48 ago, cause: power up
Last software reset at 2018-06-13 12:33, reason: User, spinning module GCodes, available RAM 6924 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0041f000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 16
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 328.9ms
MCU temperature: min 14.0, current 35.3, max 37.4
Supply voltage: min 12.1, current 12.3, max 12.6, under voltage events: 0, over voltage events: 0
Driver 0: ok, SG min/max 0/1023
Driver 1: ok, SG min/max 0/1023
Driver 2: standstill, SG min/max 0/1023
Driver 3: ok, SG min/max 0/1023
Driver 4: standstill, SG min/max not available
Date/time: 2018-06-19 13:36:20
Slowest loop: 634.02ms; fastest: 0.07ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 150, MinFreeDm 144, MaxWait: 2564388349ms, Underruns: 2227, 11
Scheduled moves: 12471, completed moves: 12441
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 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.4
=== GCodes ===
Segments left: 1
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 doing "G1 X75.697 Y152.036 E0.0121" 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: 634.09ms; fastest: 0.01ms
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 ===The error status 16 is what caught my attention but I couldn't find any info of it.
-
Is this a problem that has only occurred since you upgraded to firmware 2.0?
Layer shifts are typically caused by the nozzle catching on a blob or curl-up. Increasing motor current or reducing travel speed may help. What is the rated current of the motors, and what currents have you set in M906?
The error code bits are defined as follows:
// Enumeration of error condition bits
enum class ErrorCode : uint32_t
{
BadTemp = 1u << 0,
BadMove = 1u << 1,
OutputStarvation = 1u << 2,
OutputStackOverflow = 1u << 3,
HsmciTimeout = 1u << 4
};So 16 means that there was a timeout on the SD card interface, which is unusual.
-
I finally found the problem. It was a belt about to get cut. I didn't notice on first sight, but after a careful look I saw a dent on one of the belts (it's a coreXY), so although it did move smoothly, occasionally it got caught on one of the pulleys...
It last a year, I need to try with an original Gates.Please, delete the posts since it wasn't firmware related.
All this time (many days) I've been working with firmware 2.0. Not a single problem. The only thing that noted is that file upload to SD now reach a maximun of 750kb/s and with 1.21 it reaches 1000kb/s-
-
OK so now a new wrinkle in the Acronym soup ... Sam3 / Sam4 ????
I really dont understand many of the notes put on these github docs and find them to be a bit challenging to follow.
Id like to use FW ver 2.0 here ... for my Duet Wifi [ Duet 2 ver Board ???? ]
My DWC Page tells me - I have this stuff:
=====================
Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.02 or later [ so is that a Duet 2 or a Duet 1.02 ? ]
Firmware Version: 1.21 (2018-03-21)
WiFi Server Version: 1.21
Web Interface Version: 1.21So am I needing files for a Duet 2 Board even though the DWC interface indicates a cryptic indicator of my Electronics version of 1.02 or later vs. Duet 2 ???
Apparently i need Duet2Combined [ why its combined and with what who knows ] yes / no ?
What wifi server version files do I need to upgrade to ? [ if any ]
Do I also need a New browser interface update aka DWC / a.k.a. Web Interface Version / a.k.a. DuetWebControl.1.???
Also if any of those other files in any combination are needed - how does one know ? As well if so, what order should they be installed.
-
I agree it is fairly obtuse and complicated. An automated update system would be a boon.
You'll want the combined firmware, but if it won't take it might need to be renamed to match what you have installed already. ( I know... Complicated) this is due to the recent change which merged the duet ethernet and wifi firmwares. Hence combined.
You'll also want to grab the DWC file and the webserver file and the IAP files just in case.
Hope that helps. And hopefully the pain points of updates can be improved in the future.
-
@phaedrux said in It's out! RepRapFirmware 2.0 and 1.21.1 released:
I agree it is fairly obtuse and complicated. An automated update system would be a boon...
Hope that helps. And hopefully the pain points of updates can be improved in the future.Well said, @Phaedrux, couldn't agree more.
In my view, the firmware update structure/mechanism of the Duet and its peripherals (DWC, PanelDue, etc) is way behind the product itself.
Especially given all the firmware updates that frequently come up (great job, @dc42!), I think significantly upgrading and consolidating this aspect ought to move way up high in the priority list (if that's not the case already).
-
Thanks guys ... yeah I just punted and dl'd 3 main files [ as I dont use PanelDue ] and - installed ...
Guessed on the order... just did the main baords fw 1st then, wifiserver then DWC file.
-
They can go all at once usually. Sometimes the main firmware takes a couple attempts.
Glad it worked out
-
I'm upgrading a Fisher delta with a 0.6 Duet from 1.09k to 1.21.1 and have a problem with the web interface. On the G-Code Files listing the green, blue and red icons are not being displayed next to the files, I only get a simple selection box.
This is the same on Firefox and Chrome browsers
I have used the DuetWebControl-1.21.1.zip from https://github.com/dc42/RepRapFirmware/releases/tag/2.0
-
Click the filename to print it, or right-click on the filename to get the other options. You can also select a number of files using the check boxes and then right-click on one of the filenames.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 thanks, I discovered this after going through the web interface and it's GIT site when the changeover seems to have been made in v1.17 - is this the standard interface now and the documentation is a bit out of sync?
-
Yes, the manual is a bit out of date - I'll try to get it updated.
-
So I'm about to try to update firmware from 1.18 to 1.21 which i believe to be the most up to date. As i completely messed up the last update and had to do it the hard way I decided to just ask the questions on how to do it rather than just end up asking how to fix it. I read on wiki that to update all files you have to do them in this order: DuetWiFiFirmware, DuetWiFiServer, DuetWebControl. which makes sense as thats what I botched up before, but reading on it said Sometimes we may do synchronised releases of firmware, where more than one firmware component needs to be updated at the same time to maintain compatibility. So would have to use this option or what would be the best way to make this leap. I'm assuming I don't have to do every upgrade I have missed and can just jump to the 1.21.
-
@stevenrsearles you'll want to follow these instructions since you're still on 1.18.
There is also no reason not to upgrade straight to the 2.0 releases and skip 1.21
-
But that’s for the web control which on the list is the last to be upgraded if updating all firmware.
-
@chrisp said in It's out! RepRapFirmware 2.0 and 1.21.1 released:
@dc42 said in It's out! RepRapFirmware 2.0 and 1.21.1 released:
I have tried to reproduce this issue before several times, without success. But if you make your config.g file available, I'll try once again.
Thanks, that would be great!
Below are two config file from two very different printers one uses an 06 board, the other uses an 85 board - the problem on both boards is the same. With any FW later than 1.19, the ethernet connectivity is broke. If a static IP isn't specified then the board constantly boot loops. If a staic IP is defined, the boards will boot but I still can't access the web interface either by printer name or IP.I tried both config.g files but I was unable to reproduce the problem with either of them. Perhaps the DHCP responses from your router are different from mine.
I looked into when the problem seems to have started occurring, and it seems that it may be connected with an upgrade to a later version (2017-q2-update) of gcc. As the problem could have been triggered by a bug in that new version, I have now upgraded to an even later version (2018-q2-update). This later version spotted a buffer overflow in the netbios protocol handler in lwip (the TCP/IP stack used by RRF). I have fixed that buffer overflow. There is a small chance that it was responsible for the problem.
So please try firmware 1.21.2beta2 when I release it, which I hope will be later today or tomorrow.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 said in It's out! RepRapFirmware 2.0 and 1.21.1 released:
I tried both config.g files but I was unable to reproduce the problem with either of them. Perhaps the DHCP responses from your router are different from mine.
I looked into when the problem seems to have started occurring, and it seems that it may be connected with an upgrade to a later version (2017-q2-update) of gcc. As the problem could have been triggered by a bug in that new version, I have now upgraded to an even later version (2018-q2-update). This later version spotted a buffer overflow in the netbios protocol handler in lwip (the TCP/IP stack used by RRF). I have fixed that buffer overflow. There is a small chance that it was responsible for the problem.
So please try firmware 1.21.2beta2 when I release it, which I hope will be later today or tomorrow.
Thanks for continuing to look into this. I'm sure I enebaled reply notifications, but I did't get anything so I've only just stumbled across this again.
I've just flashed 1.22beta2 (only because it's the latest that there) and I can now connect to the board again without issue... so far
So unless this is just a one-off time that it decides that it's going to work, I'd consider this problem solved now - thanks! -
I'm glad to hear that it appears to be solved. Looks like it was either that buffer overflow bug or a bug in last year's GCC that was responsible.
-
@dc42,
I have a .gcode file that seems to completely defeat 2.01's filament and layer time estimations. While printing, through the entire print, both estimates were stuck at "n/a." (The file-based estimation showed up.) It's created with S3D 4.0.0.One aspect of the gcode that might be causing some issue (at least for the layer estimation) is that S3S is configured to "combine infill every 2 layers." I'm not sure why a filament based estimation wouldn't show up.
The file is shared on my google drive here: https://drive.google.com/open?id=1Wq_3JAKMRS9GRUJFkHIiF5ROnubqkUEt
In case you need my printer config to make any sense of this, it's here: https://drive.google.com/open?id=1v9pR4ZOSNdoJxDbj4_IW-H9HO2PL0_oR
Take care
Gary
