It's out! RepRapFirmware 2.0 and 1.21.1 released
-
Minor issue but, I think there is a discrepancy between the description of the M591 P parameter between the wiki and what the description of what the firmware reports is configured (for example when M591 D0 is sent). Ie P1 high/low conditions and P2 high/low condition. It would also be good if the wiki was explicit about which values are acceptable for C, especially that 5-9 on a Duex do not work but 10 and 11 do.
I was not getting responses from M122 or even M572. I disconnected DWC and could not reconnect.
After power cycling the machine, these are the diagnostics:
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS) running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DDM-9FAM2-LW4SD-6JTDL-3S86R-KJW3X
Used output buffers: 3 of 20 (15 max)
=== RTOS ===
Static ram: 28380
Dynamic ram: 96480 of which 0 recycled
Exception stack ram used: 348
Never used ram: 5864
Task NETWORK ready, free stack 396
Task HEAT blocked, free stack 1224
Task MAIN running, free stack 3568
=== Platform ===
Last reset 00:00:25 ago, cause: power up
Last software reset at 2018-06-05 17:18, reason: User, spinning module GCodes, available RAM 5864 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff
Error status: 0
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.6ms
MCU temperature: min 25.6, current 27.9, max 28.1
Supply voltage: min 24.1, current 24.3, max 24.4, under voltage events: 0, over voltage events: 0
Driver 0: standstill, SG min/max 0/668
Driver 1: standstill, SG min/max 0/698
Driver 2: standstill, SG min/max 0/569
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Expansion motor(s) stall indication: no
Date/time: 2018-06-05 17:41:04
Slowest loop: 7.27ms; fastest: 0.08ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 235, MaxWait: 936212058ms, Underruns: 0, 0
Scheduled moves: 11, completed moves: 11
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
=== GCodes ===
Segments left: 0
Stack records: 4 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
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 8.06ms; 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 ===
DueX I2C errors 0 -
@bmmal said in It's out! RepRapFirmware 2.0 and 1.21.1 released:
Minor issue but, I think there is a discrepancy between the description of the M591 P parameter between the wiki and what the description of what the firmware reports is configured (for example when M591 D0 is sent). Ie P1 high/low conditions and P2 high/low condition.
Are you sure? I have just compared the documentation with the code and they agree:
P1 - high when filament present, low when no filament
P2 - low when filament present, high when no filamentIt would also be good if the wiki was explicit about which values are acceptable for C, especially that 5-9 on a Duex do not work but 10 and 11 do.
Done.
I was not getting responses from M122 or even M572. I disconnected DWC and could not reconnect.
After power cycling the machine, these are the diagnostics:
...Sadly the diagnostics don't indicate anything wrong. If it happens again, if possible please connect via USB and YAT/pronterface etc. and see if you can get a M122 report that way without restarting.
-
@dc42 said in It's out! RepRapFirmware 2.0 and 1.21.1 released:
@bmmal said in It's out! RepRapFirmware 2.0 and 1.21.1 released:
Minor issue but, I think there is a discrepancy between the description of the M591 P parameter between the wiki and what the description of what the firmware reports is configured (for example when M591 D0 is sent). Ie P1 high/low conditions and P2 high/low condition.
Are you sure? I have just compared the documentation with the code and they agree:
P1 - high when filament present, low when no filament
P2 - low when filament present, high when no filamentI think the confusion might come from wiki stating output when filament present whereas
M591 Dnnn
will output state for missing filament. -
I updated to this version from the last RC and have had many issues with DWC not connecting. When I try to connect through the DWC my DuetWifi locks up? The panel due still shows a screen but I can't do anything with the buttons. The hot end fans shut off right away even though the hotends are at printing temperature.
I updated with these 3 files from the link.
Duet2CombinedFirmware.bim
DuetWiFiServer.bin
DuetWebControl-1.21.1.zipIf I don't use the DWC I can run my printer with a small issue. Last night I ran a 8 hr print without any problems. This morning I was starting a print thru Paneldue and the printer just sat idle. like I didn't choose the gcode file. So I hit the SD icon to re-select a print file and it showed zero files on the disk. I turned the printer off and back on and everything worked fine. I was able to start my print just like I always do.
Background info,
When I did the update everything went well, no problems with any of the updates. Then I went to home the printer and got an error that there was not homeall.g file. I checked the system file list and no files were present? This was while using the DWC. So I restarted my printer and the DWC and the DWC has never connected again? I can run through the paneldue but not the DWC, it just locks up my DuetWiFi board.Did I miss something? I have never had an issue with updates before.
Please advise,
I use google chrome for the DWC.
-
@timcurtis67 said in It's out! RepRapFirmware 2.0 and 1.21.1 released:
I updated to this version from the last RC and have had many issues with DWC not connecting. When I try to connect through the DWC my DuetWifi locks up? The panel due still shows a screen but I can't do anything with the buttons. The hot end fans shut off right away even though the hotends are at printing temperature.
I updated with these 3 files from the link.
Duet2CombinedFirmware.bim
DuetWiFiServer.bin
DuetWebControl-1.21.1.zipIf I don't use the DWC I can run my printer with a small issue. Last night I ran a 8 hr print without any problems. This morning I was starting a print thru Paneldue and the printer just sat idle. like I didn't choose the gcode file. So I hit the SD icon to re-select a print file and it showed zero files on the disk. I turned the printer off and back on and everything worked fine. I was able to start my print just like I always do.
Background info,
When I did the update everything went well, no problems with any of the updates. Then I went to home the printer and got an error that there was not homeall.g file. I checked the system file list and no files were present? This was while using the DWC. So I restarted my printer and the DWC and the DWC has never connected again? I can run through the paneldue but not the DWC, it just locks up my DuetWiFi board.Did I miss something? I have never had an issue with updates before.
Please advise,
I use google chrome for the DWC.
I'm sorry to hear you are having problems. Which firmware version were you running before?
I suggest you connect via USB using YAT or pronterface on a PC and send M122 to get a diagnostic report. Also send M39 to check the SD card status (you can also do the M39 from PanelDue). Firmware 1.20 and earlier weren't too fussy if the card detect pin on the SD card socket wasn't working, but 1.21 and 2.0 have tightened this up.
-
@dc42 I was running 2.0RC6. I will try to use the USB tonight to get the M122 report.
I wanted to try reinstalling all 3 firmwares to make sure I didn't get one mixed up with an older one. I was pretty careful but anything is possible....
Can I re install the DuetWifiServer.bin file and the DuetWebControl-1.21.1.zip via USB? I'm not sure how to do it that way?
Also maybe something is up with my SD card if you "tightened" up the SD card detect pin? I will try removing and re-inserting the SD card before I try anything else.
-
The DuetWiFiServer.bin file hasn't changed since version 1.21.
If you want to reinstall Duet2CombinedFirmware.bin and DuetWiFiServer.bin using USB, you will need to move the SD card to a PC and copy those files into the /sys folder. Then with the SD card back in the Duet, restart the Duet. Send M997 S1 to install the wifi binary, and M997 S0 to install the main binary (it will disconnect while you do this, but you should be able to reconnect about 30 seconds later).
To upgrade DWC, with the SD card in the PC you can rename the /www folder to /www-old, create a new /www folder, and extract the contents of DuetWebControl-1.21.1.zip into it.
-
Thank you David. I will try that tonight after I try re-inserting the SD card. I'm hoping that I don't have a bad SD card detect pin (maybe it's been that way all along). The more I think about it the more it seems like that is the issue.
What would be the "work around" if that turns out to be the case?
-
@dc42 said in It's out! RepRapFirmware 2.0 and 1.21.1 released:
Are you sure? I have just compared the documentation with the code and they agree:
P1 - high when filament present, low when no filament
P2 - low when filament present, high when no filamentI was not getting responses from M122 or even M572. I disconnected DWC and could not reconnect.
After power cycling the machine, these are the diagnostics:
...Sadly the diagnostics don't indicate anything wrong. If it happens again, if possible please connect via USB and YAT/pronterface etc. and see if you can get a M122 report that way without restarting.
I think someone below figured out my confusion between the m591 response and the wiki info.
I came in this morning and had the same issue where the machine did not give a response to M122 via DWC. I connected with YAT without resetting the machine. Not sure how to get YAT to better format the response but here it is:
=== Diagnostics ===<LF>RepRapFirmware for Duet 2 WiFi/Ethernet version 2.0(RTOS) running on Duet Ethernet 1.02 or later + DueX5<LF>Board ID: 08DDM-9FAM2-LW4SD-6JTDL-3S86R-KJW3X<LF>Used output buffers: 1 of 20 (16 max)<LF>=== RTOS ===<LF>Static ram: 28380<LF>Dynamic ram: 96552 of which 0 recycled<LF>Exception stack ram used: 468<LF>Never used ram: 5672<LF>Task NETWORK ready, free stack 324<LF>Task HEAT blocked, free stack 1200<LF>Task MAIN running, free stack 3568<LF>=== Platform ===<LF>Last reset 14:29:18 ago, cause: power up<LF>Last software reset at 2018-06-05 17:43, reason: User, spinning module GCodes, available RAM 5864 bytes (slot 1)<LF>Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0041f000, BFAR 0xe000ed38, SP 0xffffffff<LF>Error status: 24<LF>Free file entries: 9<LF>SD card 0 detected, interface speed: 20.0MBytes/sec<LF>SD card longest block write time: 0.0ms<LF>MCU temperature: min 26.8, current 27.3, max 27.5<LF>Supply voltage: min 24.1, current 24.3, max 24.5, under voltage events: 0, over voltage events: 0<LF>Driver 0: standstill, SG min/max not available<LF>Driver 1: standstill, SG min/max not available<LF>Driver 2: standstill, SG min/max not available<LF>Driver 3: standstill, SG min/max not available<LF>Driver 4: standstill, SG min/max not available<LF>Driver 5: standstill, SG min/max not available<LF>Driver 6: standstill, SG min/max not available<LF>Driver 7: standstill, SG min/max not available<LF>Driver 8: standstill, SG min/max not available<LF>Driver 9: standstill, SG min/max not available<LF>Expansion motor(s) stall indication: yes<LF>Date/time: 2018-06-06 08:14:33<LF>Slowest loop: 4.38ms; fastest: 0.09ms<LF>=== Move ===<LF>Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0<LF>Scheduled moves: 12, completed moves: 12<LF>Bed compensation in use: none<LF>Bed probe heights: 0.000 0.000 0.000 0.000 0.000<LF>=== Heat ===<LF>Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1<LF>Heater 0 is on, I-accum = 0.0<LF>=== GCodes ===<LF>Segments left: 0<LF>Stack records: 4 allocated, 0 in use<LF>Movement lock held by null<LF>http is idle in state(s) 0<LF>telnet is idle in state(s) 0<LF>file is idle in state(s) 0<LF>serial is ready with "m122" in state(s) 0<LF>aux is idle in state(s) 0<LF>daemon is idle in state(s) 0<LF>queue is idle in state(s) 0<LF>autopause is idle in state(s) 0<LF>Code queue is empty.<LF>=== Network ===<LF>Slowest loop: 1.03ms; fastest: 0.01ms<LF>Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)<LF>HTTP sessions: 0 of 8<LF>Interface state: 5<LF>=== Filament sensors ===<LF>Extruder 0 sensor: no filament<LF>Extruder 2 sensor: ok<LF>=== Expansion ===<LF>DueX I2C errors 0<LF>ok<LF>
-
@timcurtis67 said in It's out! RepRapFirmware 2.0 and 1.21.1 released:
Thank you David. I will try that tonight after I try re-inserting the SD card. I'm hoping that I don't have a bad SD card detect pin (maybe it's been that way all along). The more I think about it the more it seems like that is the issue.
What would be the "work around" if that turns out to be the case?
Here is a photo showing the position of the CD pin.
Take a look at it, using magnification if possible, and see whether it looks properly soldered to the pad or is just resting on top of it.
If the CD pin does cause issues then in recent firmware versions you should see error messages telling you that the SD card has been removed with open files on it.
-
@dc42 Thank you, I will check it out tonight and advise.
-
dc42, what happens if you have a 0 bytes config.g ? should the firmware run config.g.bak ?
I have several times a 0 bytes config.g after power-off cycle
-
To expand further on my issue of not getting responses, it seems that DWC is somehow getting out of sync but not disconnecting ie, a print was started and it did not automatically go to the Print Status screen. DWC still indicated that the machine was connected. I made a change to config.g, the file got updated (confirmed by looking after saving) and DWC asked if I wanted to reboot as if the machine was not printing even though it was. Manually going to the status page, it did not appear that the machine was printing. Refreshing the browser did however update properly.
-
Hello
little Problem with
Web Interface Version: 1.21.1
there is only 1 Fan slider
on 1.21 you have sliders for all 3 PWM Fans (if activated)thanks
Ingo (Knaudler)
-
@dc42 I got my install working perfect now. I tried taking the SD card out a few times but that made no difference so I copied the firmwares to my SD card and activated the installs with my PanelDue. It worked great that way. No need for USB interfacing.
On a side note I did notice when I was having my issues with the first install I saw that the blue LEDs were lit up in the Wifi module but not blinking and they were barely lit. If that means anything?
I must have gotten a bad install on one of the firmwares the first time but all is well now.
Thank you for the help!
-
Using it on WorkBee since released. No problems so far!
-
I have some Duest 06 that I'm still having the same issues with as was mentioend previously in 1.20 with regards to not using static IPs (https://forum.duet3d.com/topic/3508/firmware-1-20-released/75).
To confirm, if a static IP isn't provided using M552 then the Duet will work fine and can be controlled over USB and/or a PanelDue as long as the ethernet is disconnected. Before plugging in the ethernet, this is the output of M112:
=== Diagnostics ===
RepRapFirmware for Duet version 1.21.1 running on Duet 0.6
Used output buffers: 1 of 16 (2 max)
=== System ===
Static ram: 44628
Dynamic ram: 41348 of which 40 recycled
Stack ram used: 2920 current, 4400 maximum
Never used ram: 7888
=== Platform ===
Last reset 00:00:07 ago, cause: power up
Last software reset time unknown, reason: Stuck in spin loop, spinning module Network, available RAM 7080 bytes (slot 2)
Software reset code 0x2041 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0440f80f, BFAR 0xe000ed38, SP 0x20087cdc
Stack: 000c4127 00000001 fffffff9 20087b98 20087c41 80000000 00000001 2007a524 000ac0bd 000ac0bc 61000000 000000b5 00000004 000bdcd9 000afa53 0000003a 00000001 00000006 2007a900 20087d56 2007aa40 20087d90 20087d50 00000023
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 21.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 30.3, current 36.6, max 36.6
Date/time: 1970-01-01 00:00:00
Slowest loop: 1.16ms; fastest: 0.10ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 100, MinFreeDm 100, 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 heaters = 0, chamberHeaters = -1 -1
=== 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 ===
Free connections: 16 of 16
Free transactions: 24 of 24
Locked: 0, state: 2, listening: 0, 0, 0
okImmediately after plugging in the ethernet, this is the output:
=== Diagnostics ===
RepRapFirmware for Duet version 1.21.1 running on Duet 0.6
Used output buffers: 1 of 16 (7 max)
=== System ===
Static ram: 44628
Dynamic ram: 41348 of which 40 recycled
Stack ram used: 2920 current, 5128 maximum
Never used ram: 7160
=== Platform ===
Last reset 00:00:48 ago, cause: power up
Last software reset time unknown, reason: Stuck in spin loop, spinning module Network, available RAM 7080 bytes (slot 2)
Software reset code 0x2041 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0440f80f, BFAR 0xe000ed38, SP 0x20087cdc
Stack: 000c4127 00000001 fffffff9 20087b98 20087c41 80000000 00000001 2007a524 000ac0bd 000ac0bc 61000000 000000b5 00000004 000bdcd9 000afa53 0000003a 00000001 00000006 2007a900 20087d56 2007aa40 20087d90 20087d50 00000023
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 21.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 36.6, current 39.5, max 39.6
Date/time: 1970-01-01 00:00:00
Slowest loop: 3.99ms; fastest: 0.10ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 100, MinFreeDm 100, 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 heaters = 0, chamberHeaters = -1 -1
=== 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 ===
Free connections: 16 of 16
Free transactions: 24 of 24
Locked: 0, state: 3, listening: 0, 0, 0
okShortly after, however, everything locks up and neither the serial over USB or PandelDue respond. After unplugging the ethernet, and waiting a short while (without power-cycling or resetting) I can issue an M122 again, and this is the response:
=== Diagnostics ===
RepRapFirmware for Duet version 1.21.1 running on Duet 0.6
Used output buffers: 1 of 16 (2 max)
=== System ===
Static ram: 44628
Dynamic ram: 41348 of which 40 recycled
Stack ram used: 2920 current, 4400 maximum
Never used ram: 7888
=== Platform ===
Last reset 00:00:12 ago, cause: software
Last software reset time unknown, reason: Stuck in spin loop, spinning module Network, available RAM 7884 bytes (slot 0)
Software reset code 0x2041 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0440f80f, BFAR 0xe000ed38, SP 0x20087e64
Stack: 000c4127 00000001 fffffff9 89cdcd64 20087ebc 20070ff4 00000001 20087ebc 000aac3d 000a9c2c a1000000 20073788 2007a868 0000012c 00000113 00000000 20073778 200737b4 0000011f 2007add8 000000f0 00000045 81cdcd89 20073778
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 21.0MBytes/sec
SD card longest block write time: 0.0ms
MCU temperature: min 39.3, current 39.9, max 40.3
Date/time: 1970-01-01 00:00:00
Slowest loop: 1.17ms; fastest: 0.10ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 100, MinFreeDm 100, 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 heaters = 0, chamberHeaters = -1 -1
=== 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 ===
Free connections: 16 of 16
Free transactions: 24 of 24
Locked: 0, state: 2, listening: 0, 0, 0
ok -
I have just tried the same on an 85 board and can confirm that it does the same. Dropping back down to 1.19 makes everything work again (minus the new features ofc).
-
@demonio669 said in It's out! RepRapFirmware 2.0 and 1.21.1 released:
dc42, what happens if you have a 0 bytes config.g ? should the firmware run config.g.bak ?
Only in the version 2.0 release firmware.
-
@knaudler said in It's out! RepRapFirmware 2.0 and 1.21.1 released:
Hello
little Problem with
Web Interface Version: 1.21.1
there is only 1 Fan slider
on 1.21 you have sliders for all 3 PWM Fans (if activated)thanks
Ingo (Knaudler)
With DWC 1.21.1 and RRF 2.0/1.21.1 you are able to control all fans that are not set up as thermostatically controlled.