Software bundle 3.4.0 Release Candidate 2 available
-
We're happy to announce the second release candidate of software version 3.4. If you can, please upgrade to this version and provide feedback in case you encounter any problems.
If everything goes well, this version will become v3.4 stable without further changes. Apart from the highlights since RC1 there is now additional support for JPEG thumbnails, improved support for newer thumbnail encodings, and bug fixes.
Please follow the Upgrade Notes section to avoid potential pitfalls:
- RRF release notes: https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-RC#reprapfirmware-340rc2 if you are coming from release 3.3, or https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-340-post-beta7 if you are coming from 3.4beta7
- DWC release notes: https://github.com/Duet3D/DuetWebControl/wiki/Changelog-DWC-3.x-RC#version-34-rc2
- DSF release notes: https://github.com/Duet3D/DuetSoftwareFramework/wiki/Changelog-DSF-3.x-RC#version-34-rc2
For users operating their Duets in standalone mode, the firmware files can be obtained from https://github.com/Duet3D/RepRapFirmware/releases/tag/3.4.0rc2. Users in SBC mode can update using the regular apt update/upgrade path.
-
Running Sudo apt update and Sudo apt upgrade in SBC mode has updated everything apart from RRF on both the 6HC and 3HC both still reporting version 3.4.0rc1
M122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.4.0rc1 (2022-02-09 10:28:13) running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode) Board ID: 08DGM-9T66A-G63SJ-6J1D8-3SD6R-KV0BA Used output buffers: 1 of 40 (24 max) === RTOS === Static ram: 150984 Dynamic ram: 66676 of which 0 recycled Never used RAM 132748, free system stack 154 words Tasks: SBC(ready,0.6%,482) HEAT(notifyWait,0.0%,321) Move(notifyWait,0.0%,255) CanReceiv(notifyWait,0.0%,797) CanSender(notifyWait,0.0%,356) CanClock(delaying,0.0%,339) TMC(notifyWait,7.7%,58) MAIN(running,91.5%,923) IDLE(ready,0.1%,30), total 100.0% Owned mutexes: HTTP(MAIN) === Platform === Last reset 00:06:52 ago, cause: software Last software reset at 2022-02-23 16:07, reason: User, GCodes spinning, available RAM 133272, 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 Step timer max interval 134 MCU temperature: min 22.3, current 24.3, max 24.4 Supply voltage: min 23.9, current 24.0, max 24.0, 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 Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0 Events: 0 queued, 0 completed Driver 0: pos 10100, standstill, SG min 0, mspos 632, reads 8069, writes 17 timeouts 0 Driver 1: pos 19900, standstill, SG min 0, mspos 56, reads 8070, writes 17 timeouts 0 Driver 2: pos 4800, standstill, SG min 0, mspos 504, reads 8082, writes 5 timeouts 0 Driver 3: pos 12250, standstill, SG min n/a, mspos 8, reads 8087, writes 0 timeouts 0 Driver 4: pos 0, standstill, SG min n/a, mspos 8, reads 8086, writes 0 timeouts 0 Driver 5: pos 0, standstill, SG min 21, mspos 976, reads 8071, writes 15 timeouts 0 Date/time: 2022-02-23 16:14:47 Slowest loop: 61.58ms; fastest: 0.04ms === 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, segments created 11, maxWait 117332ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 20, completed 20, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed 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, chamber heaters -1 -1 -1 -1, ordering errs 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 2756, received 6122, lost 0, boc 0 Longest wait 1ms for reply type 6013, peak Tx sync delay 368, free buffers 50 (min 49), ts 1530/1530/0 Tx timeouts 0,0,0,0,0,0 === SBC interface === Transfer state: 4, failed transfers: 0, checksum errors: 0 RX/TX seq numbers: 17426/17426 SPI underruns 0, overruns 0 State: 5, disconnects: 0, timeouts: 0, IAP RAM available 0x2bca8 Buffer RX/TX: 0/0-0, open files: 0 === Duet Control Server === Duet Control Server v3.4-rc2 Code buffer space: 4096 Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0 Full transfers per second: 39.22, max time between full transfers: 42.5ms, max pin wait times: 28.9ms/0.8ms Codes per second: 0.30 Maximum length of RX/TX data transfers: 6028/864
M122 B1 Diagnostics for board 1: Duet EXP3HC firmware version 3.4.0rc1 (2022-02-08 09:04:27) Bootloader ID: not available All averaging filters OK Never used RAM 158480, free system stack 200 words Tasks: Move(notifyWait,0.0%,160) HEAT(notifyWait,0.0%,100) CanAsync(notifyWait,0.0%,69) CanRecv(notifyWait,0.0%,82) CanClock(notifyWait,0.0%,71) TMC(notifyWait,7.6%,99) MAIN(running,91.0%,345) IDLE(ready,0.0%,39) AIN(delaying,1.4%,263), total 100.0% Last reset 00:09:39 ago, cause: software Last software reset at 2021-08-16 15:20, reason: HardFault undefInstr imprec, available RAM 154848, slot 0 Software reset code 0x0060 HFSR 0x40000000 CFSR 0x00010400 ICSR 0x00000803 BFAR 0xe000ed38 SP 0x20003068 Task MAIN Freestk 386 ok Stack: 00000000 00000000 2001cd90 00000f0d 00001f00 000249f5 00024a6a 21000000 000252fa 21000000 c4514360 49488282 0a1a0203 84e02041 50203502 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff Driver 0: pos 0, 409.0 steps/mm,standstill, SG min n/a, mspos 8, reads 47954, writes 0 timeouts 0, steps req 0 done 0 Driver 1: pos 0, 80.0 steps/mm,standstill, SG min n/a, mspos 8, reads 47953, writes 0 timeouts 0, steps req 0 done 0 Driver 2: pos 0, 80.0 steps/mm,standstill, SG min n/a, mspos 8, reads 47953, writes 0 timeouts 0, steps req 0 done 0 Moves scheduled 0, completed 0, in progress 0, hiccups 0, step errors 0, maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0 Peak sync jitter 1/16, peak Rx sync delay 180, resyncs 0/0, no step interrupt scheduled VIN voltage: min 24.3, current 24.3, max 24.3 V12 voltage: min 12.2, current 12.2, max 12.2 MCU temperature: min 24.2C, current 26.2C, max 26.2C Last sensors broadcast 0x00001008 found 2 40 ticks ago, 0 ordering errs, loop time 0 CAN messages queued 11232, send timeouts 0, received 5048, lost 0, free buffers 37, min 37, error reg 0 dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0
-
I'm running a corexy with a duet WiFi2.
I've not used it for a while but have gone back to it. The first thing I did was to install 3.4rc1. When I went to print the x axis failed to home correctly.
I'm using optical endstops on x and y. When told to home all, Y correctly moves towards the endstop and activates it.
X however does not move towards the endstop, Instead it moves right about 50mm, away from the endstop and stops. If I tell it to home x again, it once again moves right by about 50mm.
It is like it thinks it has triggered the endstop. The endstop is connected and its LED is on, so the endstop is not being triggered by something else.
Below is what I have in my config.g and homeall.g. Has anything changed that would cause this?
In my config I have;
; Axis Limits M208 X0 Y0 Z0 S1 ; set axis minima M208 X200 Y190 Z150 S0 ; set axis maxima ; Endstops M574 X1 S1 P"xstop" ; configure active-high endstop for low end on X via pin xstop M574 Y1 S1 P"ystop" ; configure active-high endstop for low end on Y via pin ystop
My homeall.g is;
G91 ; relative positioning G1 Z5 F6000 H2 ; lift Z relative to current position G1 H1 X-200 Y-190 F1800 ; move quickly to X or Y endstop and stop there (first pass) G1 H1 X-200 ; home X axis G1 H1 Y-190 ; home Y axis G1 X5 Y5 F6000 ; go back a few mm G1 H1 X-200 F360 ; move slowly to X axis endstop once more (second pass) G1 H1 Y-190 ; then move slowly to Y axis endstop G90 ; absolute positioning G1 X30 Y15 F6000 ; go to first bed probe point and home Z G30 ; home Z by probing the bed ; Uncomment the following lines to lift Z after probing G91 ; relative positioning G1 H2 Z5 F100 ; lift Z relative to current position G90 ; absolute positioning
-
[Duet 3 with expansion boards] If an axis motor was controlled by an expansion board then if the endstop switch was already triggered when a homing move was commanded, unexpected motion sometimes occurred]
Does it mean the unexpected motion occured while printing or directly?
CheersRG
-
@gruna-studio said in Software bundle 3.4.0 Release Candidate 2 available:
Does it mean the unexpected motion occured while printing or directly?
Only when homing.
-
@dc42
Thanks -
It is like it thinks it has triggered the endstop. The endstop is connected and its LED is on, so the endstop is not being triggered by something else.
On a fresh power on, I sent a M119 and indeed the x endstop is at min stop.
-
@rushmere3d There is an interactive prompt at the end of the update process asking you if the firmware on the board(s) should be updated. Did you confirm that with Y(es)? If you are not sure, you can reinstall the RRF package (which invokes the prompt) by running
sudo apt install --reinstall reprapfirmware
. -
@paddy unfortunately many optical endstops are designed for 5V power and don't pull the endstop input down low enough when powered from 3.3V, even if they pull it low enough to light up the LED. You can usually fix this by changing a resistor on the endstop. See https://docs.duet3d.com/User_manual/Connecting_hardware/Sensors_endstops#h-33v-compatible-optical-endstop.
-
@dc42 said in Software bundle 3.4.0 Release Candidate 2 available:
@paddy unfortunately many optical endstops are designed for 5V power and don't pull the endstop input down low enough when powered from 3.3V, even if they pull it low enough to light up the LED. You can usually fix this by changing a resistor on the endstop. See https://docs.duet3d.com/User_manual/Connecting_hardware/Sensors_endstops#h-33v-compatible-optical-endstop.
thanks for the reply.
I opened the wiring loom and found a damaged wire. Apologies for the forum noise.
-
I didn't get that prompt.
When I tried to update to the unstable release a few days ago and it bricked my install I also didn't get that prompt.
However I used a new SD card and started again and that time I did get the prompt.
Seems a bit hit and miss?
-
@rushmere3d What did you get then, can you share a screenshot? The last prompt during the update process should look like this:
If the firmware version doesn't match the DSF version, things (probably) won't work well.
-
OK, so don't have a screenshot from past attempts but I did notice it said the below when I tried going for rc1 to rc2
"setting up reprapfirmware (3.4-rc1)"
I've just used the sudo apt install --reinstall reprapfirmware command you mentioned above and this time it did download and ask me to update rc2. Odd?
-
@rushmere3d Perhaps you were on a really old firmware version when you tried to upgrade to RC1. I'll try that on my bench setup.
-
When I updated to the unstable (rc1) I was on 3.3, it failed so I created a new SD card with the DuetPi lite image from the website and it worked. Then with that I tried to go to rc2 and I didn't get the update boards prompt. With the command you provided it worked.
-
Please can anyone else having issues with 3.4.0rc2 start a new thread to describe the problem.