Software bundle 3.3RC3 now available

dc42

@war4peace have you checked that you are definitely running Duet Control Server 3.3.0-rc3?

war4peace

@dc42
Yes sir.

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.3RC3 (2021-05-26 12:29:42) running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956BA-NA3TN-6J9FL-3S86T-9TBYS
Used output buffers: 1 of 40 (17 max)
=== RTOS ===
Static ram: 150784
Dynamic ram: 62264 of which 164 recycled
Never used RAM 138124, free system stack 126 words
Tasks: SBC(ready,5.3%,338) HEAT(delaying,0.0%,295) Move(notifyWait,0.0%,266) CanReceiv(notifyWait,0.0%,945) CanSender(notifyWait,0.0%,360) CanClock(delaying,0.0%,333) TMC(notifyWait,7.7%,59) MAIN(running,86.9%,922) IDLE(ready,0.0%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:42:39 ago, cause: power up
Last software reset at 2021-06-01 14:53, reason: User, GCodes spinning, available RAM 141196, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Aux1 errors 0,0,0
Step timer max interval 133
MCU temperature: min 33.0, current 42.7, max 43.0
Supply voltage: min 23.9, current 23.9, max 23.9, 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
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/438/438, gc cycles 0
Driver 0: position 40000, standstill, reads 9000, writes 20 timeouts 0, SG min/max 0/622
Driver 1: position 0, standstill, reads 9000, writes 20 timeouts 0, SG min/max 0/139
Driver 2: position 5080, standstill, reads 9001, writes 20 timeouts 0, SG min/max 0/136
Driver 3: position 0, standstill, reads 9001, writes 20 timeouts 0, SG min/max 0/956
Driver 4: position 0, standstill, reads 9001, writes 20 timeouts 0, SG min/max 0/122
Driver 5: position 0, standstill, reads 9006, writes 15 timeouts 0, SG min/max 0/0
Date/time: 2021-06-01 15:36:46
Slowest loop: 183.00ms; fastest: 0.03ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, maxWait 42917ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 70, completed moves 70, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 2], 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
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" 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.
=== CAN ===
Messages queued 22964, send timeouts 22961, received 0, lost 0, longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 49 (min 49), ts 12800/0/0
Last cancelled message type 30 dest 127
=== SBC interface ===
State: 4, failed transfers: 0
Last transfer: 1ms ago
RX/TX seq numbers: 26317/26317
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x2c8bc
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.3-rc3
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 34.23
Codes per second: 0.06
Maximum length of RX/TX data transfers: 2920/848

chrishamm

@war4peace Thanks for your feedback. I've updated DSF once again to always wait for the simulated time to be set before trying to write it to the job file, I hope that will fix it once and for all. Likewise I've improved the firmware update code a bit - with my latest code I haven't got a single failed firmware update after approx 30 successive attempts.

garyd9

@chrishamm said in Software bundle 3.3RC3 now available:

with my latest code I haven't got a single failed firmware update after approx 30 successive attempts.

You aren't superstitious, are you? If I were to say something similar about my own code, it would have most certainly failed on the 31st attempt.

chrishamm

@garyd9 Just a bit - perhaps I should attempt it again 42 times

dc42

Off-topic, but 42 is a number worth avoiding in tests. In 7-bit binary, it's a palindrome (and 0x42 is a palindrome in 8-bit binary). A colleague of mine in a previous job was testing a prototype network interface, and for the test he chose to set the 7-bit node address to 42. The board worked. It was later discovered that the wiring of the node ID switches had the bit order reversed.

war4peace

@dc42 Hence your nickname component
I am turning 42 this year. Oops.

@chrishamm Thank you very much for your dedication! I am glad (you know what I mean) to participate to feedback and help make Duet ecosystem better.

With that being said, and I know I might be pushing it, but any ballpark estimate (month granularity) for the 3.4 beta/RC? Eager to test new algorithms as well as Toolboard 1.1.

dc42

@war4peace I hope to have an early 3.4 beta this month for Duet WiFi/Ethernet and for Duet 3/3 Mini without CAN-connected boards.

war4peace

@dc42
Excellent news! I have a Duet 3 with no connected CAN boards, therefore I could test it.

peter247

@dc42 is 3.2.2 still the latest stable ?

SIam

@peter247 yes it is