@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.
@mlaustin6 said in Downgrading firmware:
Does this still apply if you are on firmware 2.01 beta 2 and want to go back to 2.0 non beta? Same with the web software? Wifi server seemed unchanged.
No. The two cases where firmware upgrade/downgrade isn't straightforward are:
On the Duet WiFi, changing between 1.18 or earlier and 1.19 or later (because the wifi server was moved off the WiFi module on to the main processor in 1.19).
On the Duet WiFi and Duet Ethernet, changing between 1.20 or earlier and 1.21 or later (because the firmware filename expected by the firmware changed to Duet2CombinedFirmware in 1.21).
@incogizmo said in New firmware 2.01 beta 2 available:
@incogizmo said in New firmware 2.01 beta 2 available:
@dc42 said in New firmware 2.01 beta 2 available:
On the Duet 2 Maestro, the 2 optional add-on drivers are now assumed to be TMC2224 with UART interface
Amazing! I will have some time on the weekend to properly test this! Along with the 7th Driver pin reversal. I will report back as soon as I can.
@dc42 got to testing it all sooner than expected. Can confirm microstepping is now applying on both addon drivers and driver 6 (7th driver) is also working as expected.
Are there any commands or anything else I can do to help you confirm all is working as expected?
Thanks for confirming this. I can't think of any other tests needed on the expansion board at present.
Ahhh... great point guys. I was not clear about UPDATING from the SD. I phrased like you can just moved the card and that puts the firmware on the new board... not true.
So, to re-summarize: (everybody probably gets this... but just in case... )
config.g is loaded from SD every time a board power cycles or otherwise boots.
config-override.g is loaded from SD every time an M501 is executed, and therefore would be loaded at power cycle and/or boot ONLY if the config.g contains an M501 (preferably somewhere near the end)
Other "whatever.g" files are loaded from SD as various events occur, like tool change, or print cancel, or...
Therefore, swapping an SD around different boards effectively "instantly updates" all the various ____.g files on the SD.
Duet/Reprap Firmware is on the SD. However, firmware RUNS (executes) from Processor flash.
Similarly, WiFi Firmware is on the SD but runs from flash in the WiFi module.
Updating Processor and/or WiFi flash can be accomplished via:
A) Uploading a properly named file via Duet Web Control (and clicking "yes" if prompted)
B) Placing a properly named file in the /sys directory of the SD card, and then issuing specific M commands.
C) Using a combination of USB, SAM-BA, and hardware reset/erase buttons.
The required names and exact steps are detailed in the various "Fallback procedures".
Yes. M119 does not give any information about the filament switches. Only X, Y, Z, Zprobe.
With filament present, the machine properties tab does properly indicate that they have not been triggered with "No" though. I can't really check with filament absent right now since the machine is printing but last time I checked the statuses when figuring out how to configure the switches it did work properly.
yeah everything is working very smoothly now but i had put my sd into my computer and did the upload that way and since it had been so long since the last time I updated I had to make the /www folder and dropped the whole dwc folder into it. Over all i really like the duet over listing to the r2d2 chatter of the arduino.
For my second fan I just set plainly this:
M106 P2 S0
it is working as wanted now: off as standard, and can be controlled when needed.
Clarification: the fan0 is also working great, maybe I explained it wrong:
. fan0 is off
. heater1 gets to at least 45°
. fan0 starts running
. heater1 gets under 45°
. fan0 stops running
That is this line: M106 P0 S1 I0 F500 H1 T45
So except for my blown mosfet on Fan1, everything here is solved, again sorry pro3d but much much thanks for your help!
Looks like your connection to Duet3D was lost, please wait while we try to reconnect.