RepRapFirmware 3.2beta4.1 now available
-
@dc42 I read the documentation before posting and I understand that but I could swear it was working ok, I might have missed it before because it was only moving 5mm.
I'm going to downgrade later today to test just as a sanity check.The Configurator puts out moves like I said for homing.
So my question is: how a "normal" user, not knowing CoreXY kinematics should move an axis in a pre homing procedure?
-
I have just updated the firmware binaries for the Duet 3 expansion boards EXP3HC, TOOL1LC and EXP1XD to fix a stack overflow when a heater fault occurs on a tool or expansion board. These now all report version 3.2beta4.1 (not 3.2beta4 as before).
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 -
Has anyone UI-issues updating the Duet Maestro? I get this message:
M997 S0 Operation has been cancelledwhen upgrading to 3.2beta4.1 - however it seems the update was successful:
M122 === Diagnostics === RepRapFirmware for Duet 2 Maestro version 3.2-beta4.1 running on Duet Maestro 1.0 Board ID: 08DJM-9X66L-LG3SJ-6JKF2-3SJ6L-KAX6R Used output buffers: 3 of 24 (11 max) === RTOS === Static ram: 23020 Dynamic ram: 97892 of which 200 recycled Never used RAM 8936, free system stack 216 words Tasks: NETWORK(ready,193) HEAT(blocked,335) TMC(blocked,117) MAIN(running,477) IDLE(ready,20) Owned mutexes: === Platform === Last reset 00:02:27 ago, cause: software Last software reset at 2020-12-06 21:23, reason: User, GCodes spinning, available RAM 8976, slot 0 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN Error status: 0x00 MCU temperature: min 44.7, current 45.2, max 45.7 Supply voltage: min 0.0, current 24.3, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes Driver 0: position 0, standstill, read errors 0, write errors 1, ifcnt 132, reads 40385, writes 8, timeouts 0, DMA errors 0 Driver 1: position 0, standstill, read errors 0, write errors 1, ifcnt 132, reads 40385, writes 8, timeouts 0, DMA errors 0 Driver 2: position 0, standstill, read errors 0, write errors 1, ifcnt 132, reads 40384, writes 8, timeouts 0, DMA errors 0 Driver 3: position 0, standstill, read errors 0, write errors 1, ifcnt 126, reads 40384, writes 8, timeouts 0, DMA errors 0 Driver 4: position 0, standstill, read errors 0, write errors 1, ifcnt 132, reads 40384, writes 8, timeouts 0, DMA errors 0 Driver 5: position 0, standstill, read errors 0, write errors 1, ifcnt 133, reads 40384, writes 8, timeouts 0, DMA errors 0 Driver 6: position 0, standstill, read errors 0, write errors 1, ifcnt 132, reads 40384, writes 8, timeouts 0, DMA errors 0 Date/time: 2020-12-06 21:42:16 Slowest loop: 25.81ms; fastest: 0.17ms I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0 === Storage === Free file entries: 10 SD card 0 detected, interface speed: 15.0MBytes/sec SD card longest read time 1.5ms, write time 0.0ms, max retries 0 === Move === FreeDm 169 (min 169), maxWait 0ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = 0 -1, chamberHeaters = -1 -1 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 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 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 Daemon is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 6.74ms; fastest: 0.02ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions HTTP sessions: 1 of 8 Interface state active, link 100Mbps full duplex -
@dc42 I performed changes in my config.g and rebooted the board at the DWC prompt to get:
G28 Error: Board 20 does not have input handle 1000 Error: Failed to enable endstopsHeater temp was 2000º
This happened only one time since the upgrade to 3.2-beta4.1
Let me lnow if you need additional info/testingM122 B20 Diagnostics for board 20: Duet TOOL1LC firmware version 3.2-beta4.1 (2020-12-03) Bootloader ID: SAMC21 bootloader version 2.1 (2020-11-03b2) Never used RAM 4432, free system stack 96 words HEAT 50 CanAsync 89 CanRecv 83 TMC 54 MAIN 316 AIN 66 Last reset 00:02:00 ago, cause: software Last software reset at 2020-11-30 00:59, reason: HardFault, available RAM 4224, slot 0 Software reset code 0x0060 ICSR 0x00000003 SP 0x200011c0 Task Stack: 20001014 0000000f 0001d3e3 00000000 20000928 0001757d 000184fe 01000000 00014822 0001491c 20001210 200032d8 00000020 00017d11 20004668 00000000 20001300 000086e5 00014822 20004678 0001491c 42eb80ae a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 Driver 0: position 0, 80.0 steps/mm, standstill, SG min/max 0/0, read errors 0, write errors 1, ifcnt 140, reads 60377, writes 9, timeouts 0, DMA errors 0 Moves scheduled 0, completed 0, in progress 0, hiccups 0 No step interrupt scheduled VIN: 24.3V MCU temperature: min 37.4C, current 37.6C, max 37.7C Ticks since heat task active 53, ADC conversions started 120796, completed 120795, timed out 0 Last sensors broadcast 0x00000000 found 0 56 ticks ago, loop time 0 CAN messages queued 512, send timeouts 0, received 1104, lost 0, free buffers 36 M122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.2-beta4.1 running on Duet 3 MB6HC v1.01 or later (standalone mode) Board ID: 08DJM-956BA-NA3TJ-6J9D2-3S06S-9V8AT Used output buffers: 1 of 40 (18 max) === RTOS === Static ram: 123292 Dynamic ram: 169120 of which 168 recycled Never used RAM 99612, free system stack 164 words Tasks: NETWORK(ready,165) ETHERNET(blocked,110) SENSORS(blocked,13) HEAT(blocked,297) CanReceiv(blocked,864) CanSender(blocked,371) CanClock(blocked,352) TMC(blocked,18) MAIN(running,1125) IDLE(ready,19) Owned mutexes: === Platform === Last reset 00:02:49 ago, cause: software Last software reset at 2020-12-06 12:03, reason: User, GCodes spinning, available RAM 99360, slot 1 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0xffffffff Task MAIN Error status: 0x00 MCU temperature: min 29.7, current 30.1, max 39.7 Supply voltage: min 24.1, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.1, current 12.1, max 12.2, under voltage events: 0 Driver 0: position 400, standstill, reads 41987, writes 19 timeouts 0, SG min/max 0/118 Driver 1: position 400, standstill, reads 41988, writes 19 timeouts 0, SG min/max 0/128 Driver 2: position 2000, standstill, reads 41989, writes 19 timeouts 0, SG min/max 0/189 Driver 3: position 0, standstill, reads 41990, writes 19 timeouts 0, SG min/max 0/83 Driver 4: position 0, standstill, reads 41999, writes 11 timeouts 0, SG min/max 0/0 Driver 5: position 0, standstill, reads 41991, writes 19 timeouts 0, SG min/max 0/88 Date/time: 2020-12-06 12:06:15 Slowest loop: 26.45ms; fastest: 0.15ms === Storage === Free file entries: 10 SD card 0 detected, interface speed: 25.0MBytes/sec SD card longest read time 2.5ms, write time 2.8ms, max retries 0 === Move === FreeDm 375 (min 373), maxWait 67323ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 2, completed moves 2, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 0 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 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 SBC is idle in state(s) 0 Daemon is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === Network === Slowest loop: 23.98ms; fastest: 0.03ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions HTTP sessions: 1 of 8 - Ethernet - State: active Error counts: 0 0 0 0 0 Socket states: 2 2 2 2 2 0 0 0 === CAN === Messages queued 706, send timeouts 0, received 725, lost 0, longest wait 222ms for reply type 6027, free buffers 47 -
Ok, I've been getting more 2000º and other missing things from the Toolboards
2 printers running 3.2beta4.1 on 6HCs and 3.2beta4.1 on the Toolboards
It seems to happen when saving config.g and accepting the reload popup -
Latest tool board firmware is now 3.2beta4.1.
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 I wrote the version bad on my post but my Toolboards run 3.2beta4.1 from the day you announced it's availability.
-
Got a problem updating to latest beta.
After upgrade printer doesn't connect to wifi anymore.When doing M587 I get an error saying another SPI transfer is pending.
Tryed rebooting but it's still stuck, any tip ?
Thanks
Edit: I solved it by manually flashing again the wifi module. Wondering what did happened
-
@KipK said in RepRapFirmware 3.2beta4.1 now available:
Edit: I solved it by manually flashing again the wifi module. Wondering what did happened
Unfortunately the firmware upload protocol defined by the manufacturer of the wifi chip does not include error detection. It appears that flashing the wifi firmware occasionally appears to succeed but leaves the wifi module running corrupt firmware.
-
After a bit of research I noticed that the filament assignment is handled by the firmware not by DWC.
So this issue is related to the firmware right?
https://forum.duet3d.com/topic/20307/duet2sbc-load-filament-not-working
The duet2sbc doesn't load the filament assigment on start up.
-
I am checking from time to time M122, and this one is particularly curious result (printing in progress):
M122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.2-beta4.1 running on Duet 3 MB6HC v1.01 or later (standalone mode) Board ID: 08DJM-956L2-G43S8-6J1D6-3SJ6R-KA0YG Used output buffers: 1 of 40 (26 max) === RTOS === Static ram: 123292 Dynamic ram: 170684 of which 112 recycled Never used RAM 98104, free system stack 116 words Tasks: NETWORK(ready,159) ETHERNET(blocked,103) HEAT(blocked,276) CanReceiv(blocked,947) CanSender(blocked,348) CanClock(blocked,349) TMC(blocked,18) MAIN(running,696) IDLE(ready,19) Owned mutexes: === Platform === Last reset 03:24:13 ago, cause: software Last software reset time unknown, reason: User, GCodes spinning, available RAM 98312, slot 1 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0xffffffff Task MAIN Error status: 0x00 MCU temperature: min 39.1, current 39.2, max 39.4 Supply voltage: min 27.1, current 27.3, max 27.4, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.1, current 12.2, max 12.2, under voltage events: 0 Driver 0: position 19983, ok, reads 22817, writes 0 timeouts 0, SG min/max 0/1023 Driver 1: position 28137, ok, reads 22817, writes 0 timeouts 0, SG min/max 0/1023 Driver 2: position 14970, ok, reads 22817, writes 0 timeouts 0, SG min/max 0/168 Driver 3: position 0, standstill, reads 22817, writes 0 timeouts 0, SG min/max not available Driver 4: position 0, standstill, reads 22817, writes 0 timeouts 0, SG min/max 0/0 Driver 5: position 0, standstill, reads 22817, writes 0 timeouts 0, SG min/max 0/0 Date/time: 2020-12-14 12:34:38 Slowest loop: 5.90ms; fastest: 0.26ms === Storage === Free file entries: 9 SD card 0 detected, interface speed: 25.0MBytes/sec SD card longest read time 2.4ms, write time 0.0ms, max retries 0 === Move === FreeDm 354 (min 344), maxWait 0ms, bed compensation in use: mesh, comp offset 0.000 === MainDDARing === Scheduled moves 971089, completed moves 971030, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state 3 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = 3 -1 -1 -1 Heater 0 is on, I-accum = 0.4 Heater 1 is on, I-accum = 0.4 === GCodes === Segments left: 1 Movement lock held by null HTTP is idle in state(s) 0 Telnet is idle in state(s) 0 File is doing "G1 X91.461 Y150.354 E0.04368" in state(s) 0 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 SBC is idle in state(s) 0 Daemon is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is not empty: Queued 'M106 S127.5����������������������������������������������������� ' for move 971061 Queued 'M106 S76.55����������������������������������������������������� ' for move 971063 2 of 16 codes have been queued. === Network === Slowest loop: 14.15ms; fastest: 0.03ms Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions HTTP sessions: 1 of 8 - Ethernet - State: active Error counts: 0 0 0 0 0 Socket states: 5 2 2 2 2 2 0 0 === Filament sensors === Extruder 0: pos 190.90, errs: frame 1 parity 0 ovrun 0 pol 0 ovdue 0 Extruder 1: pos 0.00, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0 === CAN === Messages queued 20, send timeouts 44, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 47 -
Thanks for that. The code to print the queued GCodes assumed that the commands were null-terminated, but they are not. Fixed in next beta/RC.
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 What about move number? They are not consecutive numbers. Is that OK? Was something executed Out-Of-Order ?
-
@BoA said in RepRapFirmware 3.2beta4.1 now available:
@dc42 What about move number? They are not consecutive numbers. Is that OK? Was something executed Out-Of-Order ?
No. A "queued GCode" is one that needs to be delayed until a command that has been put in the movement queue is executed. Only a few command types are queued, for example heat, fan and GPIO commands. Most of the time there will be no commands in that queue. The movement command queue is separate.
-
@dc42 anything else I can do with this?
-
@jay_s_uk said in RepRapFirmware 3.2beta4.1 now available:
@dc42 anything else I can do with this?
With what?
-
@dc42 sorry, wrong topic
-
Using Duet Wifi. Upgraded to 3.2-beta4.1. Bed heater disappeared.
Config heater info.
; >>>>>>>>>>>>>>>>>> Heaters
;Extruder
M143 S300 ; Set maximum heater temperature to 300C
M950 H1 C"e0_heat" T1 ;Extruder heater
M308 S1 P"spi.cs1" Y"rtd-max31865" R395 F50
;Bed
M308 S0 P"bedtemp" Y"thermistor" A"Bed temp" T100000 B4725 C0 R2200 ;Set thermistor + ADC parameters for heater 0
M950 H0 C"bedheat" T0
M143 H0 S110 ;Bed heat max 110 deg C
M307 H1 A385.0 C163.1 D3.3 V23.9 B0; PID ran on 01/12/2020 Heater 1 model: gain 385.0, time constant 163.1, dead time 3.3, max PWM 1.00, calibration voltage 23.9Did the port change?
-
I guess you upgraded from firmware 3.1. You now need to declare the bed heater explicitly using:
M140 H0
after creating heater 0 with M950.
-
Yesterday I tried to update to 3.2 Beta 4.1.
After the update DCS lost all communiucation to the board.
I flashed the board a 2nd time via USB to ensure that firmware was installed properly, which did not change anything.In the end I was forced to roll back to the last stable release by flashing the firmware via USB.
root@GPDMk1:/opt/dsf# /opt/dsf/bin/DuetControlServer -l debug Duet Control Server v3.2.0-beta4 Written by Christian Hammacher for Duet3D Licensed under the terms of the GNU Public License Version 3 [info] Settings loaded [info] Environment initialized [fatal] Could not connect to Duet (Timeout while waiting for transfer ready pin) [debug] System.OperationCanceledException: Timeout while waiting for transfer ready pin at DuetControlServer.SPI.DataTransfer.WaitForTransfer() in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 1081 at DuetControlServer.SPI.DataTransfer.ExchangeHeader() in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 1122 at DuetControlServer.SPI.DataTransfer.PerformFullTransfer(Boolean connecting) in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 164 at DuetControlServer.SPI.DataTransfer.Init() in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/SPI/DataTransfer.cs:line 104 at DuetControlServer.Program.Main(String[] args) in /home/christian/Duet3D/DuetSoftwareFramework/src/DuetControlServer/Program.cs:line 113 root@GPDMk1:/opt/dsf#My setup: Pi4, 4GB + Duet 3 6HC + Panel Duei7
