Posts made by curieos

@ReXT3D What settings did you end up using for Klipper? Did you set the sense resistor value to 0.076, or did you have to configure vsense somehow? I'm having some overheating issues with the example klipper config, even with the motor current set quite low.

@chrishamm I bumped it up to what I believe is the max, 115200, and it's still inconsistent.

@DonStauffer It works fine on a printer that I have a Duet 3 Mini with a 12864 Display running in standalone mode.

I think it's a problem with the PanelDue. I believe the RRF team is already aware of other problems caused by it in standalone mode. The inconsistent M300 behavior is probably related.

@OwenD The SBC setup has a daemon file, but the Duet 2 setup does not. I've tried them on an SBC setup without a daemon file and it's also inconsistent.

We've been working on buzzer alerts for our machine. It's been a little frustrating because they don't play consistently. We've been testing on a Duet 2 wifi in standalone mode with a PanelDue attached, as well as the machine it's destined for. The machine is a Duet 3 6XD in SBC mode with a PanelDue. Neither of these setups play consistently. Firmware on the Duet 2 setup is is 3.5.3, and the Duet 3 setup is 3.5.2.

Examples:

M300 S5000 P100
G4 P150
M300 S5500 P100
G4 P150
M300 S6000 P100
G4 P150

M300 S6500 P69
G4 P250
M300 S6500 P69
G4 P100

Sometimes the first tone is cut off, sometimes the delay between tones varies by a significant amount, and sometimes it skips tones. Running them from the PanelDue is slightly more consistent on the Duet 2 setup.

I believe I have replicated it. I put M400s and echos into the pause and resume macros to get more useful information about user and machine position, but I think the M400s caused the issue to not happen.

It appears to occur regardless of how the machine is paused (filament monitor error or manual pause), or which interface resumes it. It appears that all it takes is one pause on the secondary tool. The ones I'm producing currently are small but noticeable, and don't occur without a pause. I believe multiple pauses create a larger shift.

I've confirmed pauses while the primary tool is active do not cause the shifting. I've also confirmed adding an M400 to the end of the resume.g file prevents this shift.

Configuration repo

@timschneider No, there are retractions in the pause and tool change files, but we do not use M207 and G10/11.

We have a customer with this issue. I've been able to reproduce it, but I haven't determined the steps required to reproduce it.

Both our machines are on 3.5.2. It's two 6XDs and two 1LCs in SBC mode with a Pi 5, using the image from April. There is also a PanelDue running the latest firmware. It appears to occur when the filament monitor detects a jam on the second toolhead.

I have theories as to what happens. It appears that it occurs specifically when a jam is detected, the print is paused, and then the print is resumed by the user without clearing the jam. It then pauses again since the jam wasn't cleared. The user then resolves the jam, resumes the print, and an offset is observed.

It may also have to do with resuming from the PanelDue. I observed this issue, more easily repeatable, with a machine that had an out of date PanelDue. I have verified with the customer that the latest version of that firmware is installed, and during all of the observed events it was on 3.5.0.

I'm still attempting to replicate the issue repeatably. I know 3.5.3 is out, but I don't want to try it until I can make the issue occur intentionally.

@chrishamm When will the new duet pi images be available?

@chrishamm Will this be fixed in a DSF update? We'd like to know if our customers will have this issue if they update in the future.

I updated the packages via apt this morning on a machine in SBC mode, and after restarting the Pi I'm getting this error:

The setup is two 6XDs and two 1LCs. The Pi is a Pi 5 running the bookworm image from April 19th. Fully rebooting the machine (cutting power) does not work.

@dc42 Mine was actually around the 3.5-4 hour mark for the print. The print I was doing was around 3.75 hours, and it paused with around 15 minutes left. There may have been a delay in the print start too, my machine is a flying gantry so I need to rerun G32 every time the motors shut off, and I may have waited a bit of time for heat soaking since I was printing ASA, so it could've been 4-4.5 hours after the restart.

It appears I too had this issue. I completed the exact same print twice on alpha 4. I didn't have my computer on to catch the error in the log, but my print was halted and it did not respond to a pause. As the log says, Duet 3 Mini 5+ wifi, and I have a Fly RRF 36 toolboard (on 3.5.2). This is on a Micron (miniaturized Voron 2.4).

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.6.0-alpha.4+3 (2024-08-28 10:03:49) running on Duet 3 Mini5plus WiFi (standalone mode)
Board ID: 3SKZN-BQ6KL-K65J0-409NS-K1X1Z-ZFT7Y
Used output buffers: 3 of 40 (23 max)
=== RTOS ===
Static ram: 92328
Dynamic ram: 98920 of which 0 recycled
Never used RAM 37916, free system stack 128 words
Tasks: NETWORK(2,nWait 7,13.5%,179) HEAT(3,nWait 6,0.0%,325) Move(4,invalid,0.2%,247) TMC(4,nWait 6,1.6%,65) CanReceiv(6,nWait 1,0.1%,771) CanSender(5,nWait 7,0.0%,327) CanClock(7,delaying,0.0%,348) MAIN(1,running,83.7%,665) IDLE(0,ready,0.0%,29) AIN(4,delaying,0.8%,255), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 19:27:32 ago, cause: software
Last software reset at 2024-08-27 14:00, reason: User, Gcodes spinning, available RAM 6052, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00487000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
MCU temperature: min 38.7, current 40.4, max 43.2
Supply voltage: min 23.6, current 23.9, max 24.3, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/10, heap memory allocated/used/recyclable 2048/832/624, gc cycles 0
Events: 1 queued, 1 completed
Date/time: 2024-08-29 08:58:29
Slowest loop: 226.13ms; fastest: 0.12ms
=== Storage ===
Free file entries: 19
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 7.8ms, write time 0.0ms, max retries 0
=== Move ===
Segments created 366, maxWait 152501ms, bed comp in use: mesh, height map offset 0.000, hiccups added 0 (0.00/0.00ms), max steps late 1, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 23270.00/23909/-0.08 -1963.00/-2663/0.85 86222.00/86221/-0.00
no step interrupt scheduled
Driver 0: standstill, SG min 0, read errors 0, write errors 1, ifcnt 109, reads 11371, writes 19, timeouts 0, DMA errors 0, CC errors 0
Driver 1: standstill, SG min 0, read errors 0, write errors 1, ifcnt 109, reads 11371, writes 19, timeouts 0, DMA errors 0, CC errors 0
Driver 2: standstill, SG min 0, read errors 0, write errors 1, ifcnt 112, reads 11369, writes 20, timeouts 0, DMA errors 0, CC errors 0
Driver 3: standstill, SG min 0, read errors 0, write errors 1, ifcnt 112, reads 11369, writes 20, timeouts 0, DMA errors 0, CC errors 0
Driver 4: standstill, SG min 0, read errors 0, write errors 1, ifcnt 112, reads 11370, writes 20, timeouts 0, DMA errors 0, CC errors 0
Driver 5: standstill, SG min 0, read errors 0, write errors 1, ifcnt 112, reads 11370, writes 20, timeouts 0, DMA errors 0, CC errors 0
Driver 6: standstill, SG min 0, read errors 0, write errors 1, ifcnt 54, reads 11379, writes 10, timeouts 0, DMA errors 0, CC errors 0
=== DDARing 0 ===
Scheduled moves 267477, completed 267437, LaErrors 0, Underruns [0, 0, 0]
=== DDARing 1 ===
Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0]
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.2
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null, null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is doing "G1 X53.835 Y60.773 E.0219" 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 1, axes/extruders owned 0x0000807
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 886806, received 1401380, lost 0, ignored 0, errs 1, boc 0
Longest wait 2ms for reply type 6039, peak Tx sync delay 282, free buffers 26 (min 25), ts 350263/350262/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 18.02ms; fastest: 0.00ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 2.1.0
MAC address e8:68:e7:e1:4d:a8
Module reset reason: Power up, Vcc 3.36, flash size 2097152, free heap 42012
WiFi IP address 192.168.1.2
Signal strength -48dBm, channel 11, mode 802.11n, reconnections 0
Clock register 00002001
Socket states: 3 0 0 0 0 0 0 0

Edit: I'd also like to report that there wasn't an improvement in pressure advance behavior. Should I be running a 3.6 alpha on my toolboard too?

@dc42 It's on the mellowfly toolboard running 3.5.2

I've done a couple prints now on my Micron, and input shaping is looking way better. There's a symptom I didn't realize was due to the old input shaping algorithm; large ringing artifacts on organic supports. My guess is it's due to the high segmentation of those moves, but I could hear the printer make an almost grinding noise. That's all gone now.

The main quirk I'm noticing is slow probing. I'm running a klicky PBC and before, when the probe triggered, it would retract near instantly. Now it pauses after triggering for a brief moment. I have it set up to do multiple samples, and it seems like the first sample is always the slowest when retracting, but every sample has a brief pause.

Pressure advance also seems kinda weird. I need to rerun the tuning pattern to be sure I'm using the correct value, but it looks like turning it on at all has a very negative effect on surface quality. It's most pronounced on the latest print, but that's still in progress.

Does alpha 4 still work with toolboards running 3.5.2? I'd like to give this a try, but the toolboard on my Micron is a Fly RRF 36 and it doesn't look like team gloomy is releasing 3.6 alpha builds.

@chrishamm Was xscreensaver installed on the older bullseye image? I'll give that a try when I get into work later, thanks!

@chrishamm I dug into this a little bit by setting up a test machine with a Pi 4 and stock Bullseye image. Looks like it's set to disable DPMS, with blanking enabled in xset and rpi config, and a timeout/cycle of 0 in xset. I replicated these settings on the Bookworm machine and it still has the incorrect behavior. Looks like there's something else missing.

@chrishamm None of those commands do what I want. I specifically want the old behavior of screen blanking from Bullseye on Pi 4 back, where after a certain period of time the screen blanks (goes black) but the display doesn't turn off completely, and when it is tapped on it comes back after a moment without registering the tap that woke it up.

The closest I can get to this behavior is with screen blanking on, dpms enabled, the s option on xset set to blank, and the monitor settings changed to not turn off when no signal is detected. I can tap on the display to bring it back up, but it takes longer since the display has to come out of standby, and it registers the tap that woke it up, which is quite dangerous.

Maybe this is a Pi 5 behavior change, I'm not certain, but the problem is when the screen blanks the monitor stops detecting a signal and turns off. Wayland was only enabled for an afternoon while I was searching for a replacement on-screen keyboard, but I don't recall this being an issue there. I can't recall if the display ever blanked, but I know for a fact that it never turned off.

We are running the Bookworm image under X11 instead of Wayland due to the lack of on-screen keyboards available for Wayland that work on the Raspbian image. I'm fairly certain Wayland has the expected behavior, where the display gets blanked but remains on, so a tap on the touch screen wakes it, but under X11 the display turns off, which requires turning it back on and tapping repeatedly in a "safe" location until the Pi wakes up (safe in this instance means a location unlikely to cause undesired machine behavior). This is a change from the older Bullseye image, which worked as expected.

I'm assuming this is simply a configuration issue. A setting which was set for X11 on the older image is not set for Bullseye since the assumption is you will be running under Wayland, but this isn't an option for us. If I could get some guidance on which setting I'm missing it would be appreciated, I am having difficulty searching for a solution to this issue.

edit: This is on a Pi 5

@dc42 Is there a DSF or DWC release to go with those? I just encountered some very strange behavior retrying that print with those binaries.

I first homed the machine before the print. Then I started the print, and it homed again (as expected), and then immediately it rehomed. It then moved to the "starting position" near the nozzle wiper, skipped over waiting for the tool to heat and wiping in the tool change macros, moved to the print start location, waited for T0 to heat up, and started printing. It then got halfway done with the skirt, retracted, and moved back to the wiping location, then moved back to where it stopped with the skirt, did the extruder priming sequence, and resumed the skirt. I then paused it, and it moved to the park position. I tried resuming, and it then properly ran the toolchange sequence, but then it went to the start of the brim and seemingly randomly extruded a few lines in varying directions, unrelated the print geometry.

The start gcode for this file is:

; Run nozzle diameter and filament check
M98 P"0:/sys/System Macros/Config Checks/nozzle_check.g" L0.6 S0.6
M98 P"0:/sys/System Macros/Config Checks/filament_check.g" L"NYLON" S"PVA"

; set extruder temp
M568 P0 S275 R170 A1
M568 P1 S210 R120 A1

; Set and wait for bed temp
M190 S80

; Home all axes
G28

; Enable mesh compensation
M98 P"0:/sys/System Macros/Config Checks/load_heightmap.g"

; Move to starting position
G0 H2 X{move.axes[0].min} Y50 F6000

; Select first tool
T0

; Move near start
G1 X251.37 Y156.171 Z2.3 F12000
G21 ; set units to millimeters
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion
T0
M116 P0 S5
; Filament gcode



M572 D0 S0.006
M107
;LAYER_CHANGE
;Z:0.3
;HEIGHT:0.3

The macros called can be found here:
https://github.com/HartSmart-Products/HSP1-I-SD-Image/tree/main

edit: Attached is the version report for all duet components