Software bundle 3.3RC3 now available

war4peace

Update tom my previous post.
I had to connect the Duet 3 6HC to USB and to a laptop, and update the firmware using BOSSA.
Everything now works correctly.

war4peace

FYI:

[Duet + SBC] RRF updated job.lastFileName as soon as the print started. This confused DSF, causing it not to append the simulated time info to the file when a simulation completed. RRF no longer reports job.lastFileName while a print is in progress.

This is still not working, I have just simulated a file and the result was not updated in the job list.

Original topic.

cosmowave

I have a Duet2 Ethernet with FW3.3b3.
When i try to install 3.3rc3 then a error occurs:

Error: M997: In-application programming binary "0:/firmware/Duet2_SDiap32_WiFiEth.bin" not found

Phaedrux

@cosmowave said in Software bundle 3.3RC3 now available:

"0:/firmware/Duet2_SDiap32_WiFiEth.bin" not found

Are you uploading that file as well? Make sure it exists in the /firmware/ folder.

cosmowave

@phaedrux
oh no! I'm so stupid!
I have to load this file separately...
I will try it in the evening. Thanks!

dc42

@war4peace said in Software bundle 3.3RC3 now available:

Update tom my previous post.
I had to connect the Duet 3 6HC to USB and to a laptop, and update the firmware using BOSSA.

That's odd, the upgrade should have been straightforward.

war4peace

@dc42
I expected as much. After almost 1h of it being stuck at 96%, I rebooted the SBC. Then, I had to flash the motherboard firmware through BOSSA.
I guess the process got stuck while writing the firmware to the motherboard and it got corrupted.

Nevertheless, it's working now, however file simulation is still broken. Just FYI, maybe you'd like to take a look at it again.

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