@jgrg1 Wiring is all good. Continuity all checks out.
On a whim, I checked the current draw on the USB step down converter I use (https://www.amazon.co.uk/dp/B08KRS85JZ). When I turned the bed heater on, the power draw shot through the roof and the device reset. I tried with a bog standard USB power brick, and even though I get the low power icon on the pi, it doesn't kill the power and works. I'm guessing the USB converter is a heap of junk.
Have to say, this project is excellent. Having never used NodeRed, it was relatively trivial to setup on my Raspberry pi 3b+ SBC board (following the instructions) and get going. I then wired up a pushover node, and voila, I now have notifications on my phone.
Essentially, I wanted to recreate the pushover notifications that you get with octoprint, and this worked a treat. It's actually more powerful, as the DSF-Event nodes let you look for specific changes with the Duet object model.
I used the DSF-Intercept node (with custom g-code added in the slicer) to check for layer changes and report when the first layer was started and finished.
Back to basics continuity check has revealed that my signal wire has a break in it somewhere. Will swap that out, and try again.
That sorted it - and it now works perfectly. Just had to invert the output.
My crimping tool mashed one of the cables, but not the other two. Shonkly cable, I guess.
@jgrg1 Wiring is all good. Continuity all checks out.
On a whim, I checked the current draw on the USB step down converter I use (https://www.amazon.co.uk/dp/B08KRS85JZ). When I turned the bed heater on, the power draw shot through the roof and the device reset. I tried with a bog standard USB power brick, and even though I get the low power icon on the pi, it doesn't kill the power and works. I'm guessing the USB converter is a heap of junk.
@droftarts Hmm, could be - it's a bedslinger. I'll check the wiring.
Hi,
I have a Duet3 Mini wifi with a Raspberry Pi 3B+ SBC. This has been working fine for 4 years. Now, whenever I try to print, the raspberry pi reboots almost immediately and I get an SBC Connection reset error. I narrowed it down to simply turning the heater on via the dashboard in DWC. So there's no stepper motor movement at all. I also made sure the Duet SD card was completely removed.
I just recently flashed a new 64gb Samsung Evo SD card with the image_2024-11-27-DuetPi-arm64.zip image (from here https://github.com/Duet3D/DuetPi/releases) using the official raspberry pi imager software. This runs the 3.5.4 Duet firmware. Also did a sudo apt update/upgrade and allowed labwc to overwrite the various .conf files as part of that upgrade. Same issue, re: SBC connection reset.
Running 'top' in a pi terminal on the new image seems to show a chromium process taking anywhere between 20% and 40% of the cpu usage - which seems high to me. I've tried killing that process and turning on the bed heater, and the pi still resets. The pi PSU seems ok.
Running the Duet in standalone mode works perfectly fine.
M122 output after a reset is:
m122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.5.4 (2024-11-24 10:44:24) running on Duet 3 Mini5plus WiFi (SBC mode)
Board ID: R4MQT-XP6KL-K65J0-409NY-3Q02Z-HYPA6
Used output buffers: 1 of 40 (17 max)
=== RTOS ===
Static ram: 103496
Dynamic ram: 108340 of which 0 recycled
Never used RAM 27060, free system stack 208 words
Tasks: SBC(2,ready,1.2%,813) HEAT(3,nWait 1,0.0%,348) Move(4,nWait 6,0.0%,355) CanReceiv(6,nWait 1,0.0%,939) CanSender(5,nWait 7,0.0%,336) CanClock(7,delaying,0.0%,334) TMC(4,nWait 6,0.8%,110) MAIN(2,running,97.1%,664) IDLE(0,ready,0.0%,29) AIN(4,delaying,0.8%,264), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:13:31 ago, cause: power up
Last software reset at 2025-04-26 00:53, reason: User, Gcodes spinning, available RAM 27040, slot 2
Software reset code 0x6003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
MCU revision 3, ADC conversions started 609192, completed 609192, timed out 0, errs 0
MCU temperature: min 28.5, current 33.6, max 33.9
Supply voltage: min 23.2, current 24.2, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/7, heap memory allocated/used/recyclable 2048/1952/1836, gc cycles 2
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, read errors 0, write errors 0, ifcnt 14, reads 32783, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 1: standstill, SG min 0, read errors 0, write errors 0, ifcnt 14, reads 32783, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 2: standstill, SG min 0, read errors 0, write errors 0, ifcnt 14, reads 32784, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 3: standstill, SG min 0, read errors 0, write errors 0, ifcnt 14, reads 32783, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 4: standstill, SG min 0, read errors 0, write errors 0, ifcnt 14, reads 32783, writes 0, timeouts 0, DMA errors 0, CC errors 0
Driver 5: not present
Driver 6: not present
Date/time: 2025-04-26 22:18:24
Cache data hit count 1807064435
Slowest loop: 4.17ms; fastest: 0.12ms
=== Storage ===
Free file entries: 20
SD card 0 not detected, interface speed: 0.0MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, max steps late 0, min interval 0, bad calcs 0, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
Moves shaped first try 0, on retry 0, too short 0, wrong shape 0, maybepossible 0
=== DDARing 0 ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== DDARing 1 ===
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, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null, 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
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x0000803
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== Filament sensors ===
check 0 clear 3856743
Extruder 0 sensor: ok
=== CAN ===
Messages queued 5606, received 0, lost 0, errs 2946270, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 26 (min 26), ts 3115/0/0
Tx timeouts 0,0,3115,0,0,2491 last cancelled message type 30 dest 127
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 3714/2591
SPI underruns 0, overruns 0
State: 5, disconnects: 5, timeouts: 5 total, 5 by SBC, IAP RAM available 0x0cd20
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.5.4 (2024-11-25 17:32:26, 64-bit)
HTTP+Executed:
> Executing M122
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 22.38, max time between full transfers: 3773.4ms, max pin wait times: 2031.7ms/10.7ms
Codes per second: 0.25
Maximum length of RX/TX data transfers: 4421/532
I've also just tried it with a brand new ribbon cable, and a freshly flashed 32Gb Sandisk ultra SD card with image_2023-09-06-DuetPi.zip + apt update/upgrade. It still crashes the pi when I turn the bed heater on.
@OwenD Cool beans. Will try that.
Hi,
just installed 3.5.1, running in SBC mode. I have a custom macro for handling filament load/unload, and I pass in the desired temperature as a parameter with name K. E.g.
M98 P"0:/macros/03-Filament_Handling/00-Load_Filament" K215 ; execute macro to load and purge filament
As of 3.5.1, I'm now getting an error when popping up a display message that uses that parameter:
if exists(param.K)
M291 P"Please wait while the nozzle is being heated up" R"Heating: " ^ {param.K} ^ "°C" S1 T5; display message
....
I get a red error popup on the web page saying "invalid character '^' on line 17"
Line 17 is the M291 call.
Have to say, this project is excellent. Having never used NodeRed, it was relatively trivial to setup on my Raspberry pi 3b+ SBC board (following the instructions) and get going. I then wired up a pushover node, and voila, I now have notifications on my phone.
Essentially, I wanted to recreate the pushover notifications that you get with octoprint, and this worked a treat. It's actually more powerful, as the DSF-Event nodes let you look for specific changes with the Duet object model.
I used the DSF-Intercept node (with custom g-code added in the slicer) to check for layer changes and report when the first layer was started and finished.
Just plugged a touchscreen into the raspberry pi, and tried to reproduce the issue. Behaviour is the same. The Duet website seems to hang. The raspberry pi is still responsive, so I think it's the Duet board itself that hangs.
@chrishamm Apologies, only just saw this.
When it gets stuck, if I Send Code M122 via DWC, the UI displays a spin/wait graphic, but does nothing, and there is no response.
Is M122 "DSF" different? Is it possible to do this via a USB connection and YAT?
I have the following integrated plugins:
Accelerometer (stopped)
Height Map (started)
G-Code viewer (started)
Object model browser (started)
On-Screen keyboard (stopped)
And External plugins:
DuetPi Management plugin (started)
I'm using the https://pkg.duet3d.com/DuetPi.zip image that I burnt uising balenaEtcher. I also did the sudo apt upgrade, and sudo apt dist-upgrade after installation.
The below is the output of M122 "DSF" when it is not stuck - it's actually printing right now:
M122 "DSF"
=== Duet Control Server ===
Duet Control Server v3.4.5
File /opt/dsf/sd/gcodes/ShelfSupport_Triple_0.25mm_PLA_E0.974_MK2.5S_2h53m.gcode is selected, processing
File:
Buffered code: G1 E.5 F2100
Buffered code: M204 P1200
Buffered code: G1 F3600
Buffered code: G1 X81.429 Y103.504 E.04466
Buffered code: G1 X80.813 Y103.452 E.02494
Buffered code: G1 X82.014 Y104.653 E.06853
Buffered code: G1 X81.986 Y105.189 E.02166
Buffered code: G1 X80.002 Y103.205 E.11324
Buffered code: M204 P1000
Buffered code: G1 E-.5 F2100
Buffered code: G1 Z1.45 F720
Buffered code: G1 X80.285 Y92.775 F7200
Buffered code: G1 Z1.25 F720
Buffered code: G1 E.5 F2100
Buffered code: M204 P1200
Buffered code: G1 F3600
Buffered code: G1 X79.694 Y92.183 E.03375
Buffered code: G1 X79.635 Y92.688 E.02052
Buffered code: G1 X80.066 Y93.119 E.02458
Buffered code: G1 X80.007 Y93.624 E.02052
Buffered code: G1 X79.576 Y93.193 E.02458
Buffered code: G1 X79.517 Y93.698 E.02052
Buffered code: G1 X79.948 Y94.129 E.02458
Buffered code: G1 X79.889 Y94.634 E.02052
Buffered code: G1 X79.458 Y94.203 E.02458
Buffered code: G1 X79.399 Y94.708 E.02052
Buffered code: G1 X79.83 Y95.138 E.02458
Buffered code: G1 X79.771 Y95.643 E.02052
Buffered code: G1 X79.34 Y95.213 E.02458
Buffered code: G1 X79.281 Y95.718 E.02052
Buffered code: G1 X79.712 Y96.148 E.02458
Buffered code: G1 X79.653 Y96.653 E.02052
==> 1416 bytes
Code buffer space: 2688
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 2.87, max time between full transfers: 142.6ms, max pin wait times: 94.5ms/31.9ms
Codes per second: 0.61
Maximum length of RX/TX data transfers: 3100/1464
@Phaedrux Hi, it's not resolved. The issue still remains in SBC mode. The issue is not present in standalone mode.
I've just tried in standalone mode, I've just uploaded the exact same system set to a different 32Gb SanDisk Extreme Pro SD card, and the pause/resume works. But SBC mode still does not work.