RepRapFirmware 3.6.0-alpha.4+3 available for testing

edsped

Day 3 without any tool drops so I'm going to say inserting M400 prior to tool lock/unlock macros is working. Out of curiosity, will this be addressed in the final release or will the M400 always be required? It won't matter much for me as I'll likely forget to remove it when the 3.6 is released but I am curious.

dc42

@edsped I haven't decided yet. We'd need to either disable IS throughout tool change files, or implicitly wait for motion to stop between certain pairs of moves - but what pairs, exactly? I'm not sure that either of those would be appropriate in all circumstances. We could add a means of specifying that a certain axis is used as a tool locking mechanism, but would that be any better than advising users where to use M400?

oliof

If people don't want to sprinkle M400s, they could also disable and re enable IS at the beginning and end of the macros.

dc42

@oliof yes. I am considering extending M593 to allow IS to be turned off and then turned on again without needing to specify the parameters.

Kiolia

Okay, I'm back with a problem report with my delta. I noticed during extrusion "blob" testing tonight that it was making a light clunking noise during each blob extrude. At first I assumed it was the extruder, but it was happening on all the blobs, and doing it the most on the lowest cubic (slowest) ones. To judge from finger-on-arms, it may only be the Z axis (AWD, so this is two steppers). IS on/off does not affect it. It is reproducible without extrusion, too, using a very slow move with Z component like G1 X3 Y1 Z20.5 F16.84 starting from X0 Y0 Z1. There is no discernible interval to the clunking; it sounds random, and it happened at least once on most of the blobs, which were done across the bulk of the bed area. M122 shows nothing amiss to my eyes. I can confirm that this wasn't happening with nigh-identical GCode in 3.5.1. I think I've seen this or something similar reported already, but I thought that was connected somehow to IS, and this doesn't seem to be.

droftarts

@Kiolia Hi, thanks for your report. I think this may be related to this issue: https://github.com/Duet3D/RepRapFirmware/issues/1015. I don't think this has been fixed in 3.6.0 yet, so one for @dc42.

Ian

droftarts created this issue in Duet3D/RepRapFirmware

open Input shaping on linear delta causes Z motor clunking at specific bed locations #1015

Kiolia

@droftarts Some additional test results. At least for me, it is new for 3.6.0 and specific to very slow moves, not IS or bed location-related. I executed the following sequence of moves this morning, starting from X0 Y0 Z1, and heard the noise (which sounds like a light motor skip) multiple times on all 6. With the exception of move number 4, which had many skip/clunk noises throughout, the starts of the moves did NOT make noises at first -- I would estimate at least the first 10-15 seconds of the other 5 were all noise-free.

dc42

@Kiolia thanks, I'll test this on my own delta next week. @droftarts can you test this too?

Kiolia

@dc42 If it's needed for repro, I'm running x32 on 0.9s / 16Ts for 400 steps / mm and set segmentation to 400/sec 0.2mm min length. (if you need the rest of my config let me know.) I haven't tested to see if there's a specific speed threshold for the behavior, but the way that the noises often don't start for some seconds makes me wonder if the duration of the move is a factor, rather than just the speed.

balajiramani

I just started a long print (6+ hours) and approximately 2.5 hours into the print, the job failed with the "Error: Movement halted because a step timing error occurred (code 3). Please reset the controller." error. This is with the 3.6.0-alpha.5+1 firmware.

Here is the output of M112 right after the error:

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.6.0-alpha.5+1 (2024-08-31 17:50:58) running on Duet WiFi 1.0 or 1.01
Board ID: 08DAM-999TL-MQ4SD-6JTDL-3SS6N-968BX
Used output buffers: 13 of 26 (21 max)
=== RTOS ===
Static ram: 23360
Dynamic ram: 67504 of which 12 recycled
Never used RAM 11864, free system stack 102 words
Tasks: NETWORK(2,nWait 6,15.3%,195) HEAT(3,nWait 5,0.1%,309) Move(4,invalid,5.2%,266) MAIN(1,running,79.4%,752) IDLE(0,ready,0.0%,29), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 02:31:01 ago, cause: software
Last software reset at 2024-09-16 11:25, reason: User, Gcodes spinning, available RAM 28192, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 27.7, current 48.5, max 49.4
Supply voltage: min 23.5, current 24.2, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/2, heap memory allocated/used/recyclable 2048/1132/1072, gc cycles 1
Events: 0 queued, 0 completed
Date/time: 2024-09-16 13:56:21
Slowest loop: 218.04ms; fastest: 0.13ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 8
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 9.4ms, write time 3.1ms, max retries 0
=== Move ===
Segments created 639, maxWait 442509ms, bed comp in use: none, height map offset 0.000, hiccups added 5 (0.15ms), max steps late 1, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 68366.00/68371/-0.79 66822.00/66848/-0.92 76754.00/76740/0.84
no step interrupt scheduled
Driver 0: standstill, SG min 0
Driver 1: standstill, SG min 0
Driver 2: standstill, SG min 0
Driver 3: standstill, SG min 0
Driver 4: standstill, SG min n/a
Driver 5: 
Driver 6: 
Driver 7: 
Driver 8: 
Driver 9: 
Driver 10: 
Driver 11: 
=== DDARing 0 ===
Scheduled moves 912010, completed 912008, LaErrors 0, Underruns [17, 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.1
Heater 1 is on, I-accum = 0.2
=== GCodes ===
Movement locks held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is doing "G1 X-6.539 Y47.848" 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Q0 segments left 1
Code queue 0 is empty
=== Network ===
Slowest loop: 195.01ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(4) 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 5c:cf:7f:2c:25:00
Module reset reason: Turned on by main processor, Vcc 3.40, flash size 4194304, free heap 40984
WiFi IP address 192.168.1.61
Signal strength -28dBm, channel 6, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

Here is config.g:

; Setup some global variables
global power_fail_retract = 2   ;  Retract 2mm when power fails

; Communication and general
M550 P"BigDelta"				        ; Machine name and Netbios name (can be anything you like)
M551 Preprap                        	; Machine password (used for FTP)
M552 S1					                ; Enable WiFi. Disabled for setup and testing. Enable once set up on your network.

; Enable telnet
M586 S1 P2

; Debugging
M111 S0                                 ; Debug off
M929 P"eventlog.txt" S1                 ; Start logging to file eventlog.txt

M555 P2                           	    ; Set output to look like Marlin
G21                                 	; Work in millimetres
G90                                	    ; Send absolute coordinates...
M83                                 	; ...but relative extruder moves

; Axis and motor configuration
M569 P0 S0				; Drive 0 goes backwards
M569 P1 S0				; Drive 1 goes backwards
M569 P2 S0				; Drive 2 goes backwards
M569 P3 S0				; Drive 3 goes backwards

; Assign extruder drive
M584 E3


; Set homing switch config
M574 X2 S1 P"!xstop"        ; Set homing switch configuration on S1 = high-end, active-low
M574 Y2 S1 P"!ystop"        ; Set homing switch configuration on S1 = high-end, active-low
M574 Z2 S1 P"!zstop"        ; Set homing switch configuration on S1 = high-end, active-low

; Set it as a linear delta
M669 K3

; Setup paneldue 5i
M575 P1 S1 B57600

M665 R215.062 L395.317:395.475:395.433 B160 H374.050		; set delta radius, diagonal rod length, printable radius and homed height
M666 X0 Y0 Z0				; put your endstop adjustments here, or let auto calibration find them
M350 X16 Y16 Z16 E16 I1    	; Set 16x microstepping with interpolation
M92 X200 Y200 Z200			; Set axis steps/mm

M906 X1400 Y1400 Z1400 E1400 I60	; Set motor currents (mA) and increase idle current to 60%
M84 S60                             ; Set idle timeout
M201 X12000 Y12000 Z2000 E10000     ; Accelerations (mm/s^2)
M203 X30000 Y30000 Z5000 E3600		; Maximum speeds (mm/min)
;M566 X900 Y900 Z300 E1200 P1		; Maximum instant speed changes mm/minute
;M566 X300 Y300 Z300 E450 P1        ; Maximum instant speed changes mm/minute
M566 X600 Y600 Z300 E900 P1		    ; Maximum instant speed changes mm/minute
M204 P9000 T9000                    ; Set acceleration for print and travel moves

; Configure Input shaping
M593 P"zvdd" F45

; Thermistors
M308 S0 P"bed_temp" Y"thermistor" T100000 B3950 R4700 H30 L0	; Put your own H and/or L values here to set the bed thermistor ADC correction
M308 S1 P"e0_temp" Y"thermistor" T100000 B3950 R4700 H30 L0	; 100K NTC 
;M308 S1 P"e0_temp" Y"thermistor" T100000 B4658 C6.5338987554e-08 ; 104-NT Aliexpress thermistor

M950 H0 C"bed_heat" T0      ; Set up H0 as the bed heater using T0 as the sensor
M950 H1 C"e0_heat" T1       ; Set up H1 as the extruder heater using T1 as the sensor
M140 H0                     ; Map H0 as the bed heater

; Set temperature excursion warnings
M570 H0 P20
M570 H1 P20

M308 S3 Y"mcu-temp" A"MCU" ; configure sensor 3 as thermistor on pin e1temp for left stepper
M308 S4	Y"drivers"  A"Drivers"  ; configure sensor 4 as temperature warning and overheat flags on the TMC2660 on Duet
M912 P0 S-3.5               ; Calibrate MCU temp

; Fan definitions
M950 F0 C"fan0"
M950 F1 C"fan1"
M950 F2 C"fan2"

; Thermostatic fan on 1 for cooling the hotend
M106 P1 T50 H1
; Thermostatic fan on 2 for cooling the board
M106 P2 H3:4 L.3 X1 B0.3 T35:70 ; set fan 2 value

; Tool definitions
M563 P0 D0 H1                       	; Define tool 0
G10 P0 S0 R0                        	; Set tool 0 operating and standby temperatures
;M92 E1392								; Based on https://www.thingiverse.com/thing:1359717; 2023/01/06
M92 E1077.1646                          ; This is the new value for the hobb-goblin extruder.  03/07/2023
;M92 E319.2005                           ; Set extruder steps per mm.  This is for the MK8 gear

; Z probe and compensation definition
M558 P8 C"^!zprobe.in" R0.4 H4 F1200 T6000 A5 S0.01	; Z probe is a piezo sensor
G31 X0 Y0 Z-0.08 P100			; Set the zprobe height and threshold
M557 R150 S20				; Probe within a radius of 150mm and mesh spacing of 20
M376 H5                     ; Taper off bed compensation after 5mm

; Configure power failure and resume
M911 S21.0 R23.0 P"G91 M83 G1 Z3 E{-global.power_fail_retract} F1000" ; Relative movement and extrusion.  Move head up and retract 2mm filament.

M208 S1 Z-0.5				; set minimum Z
T0					        ; select first hot end

M501					    ; Load any config overrides

MaxGyver

@dc42 I just had the same error as reported by @balajiramani . In my case, the error occurred during the first layer of a print job.

=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.6.0-alpha.5+1 (2024-08-31 17:51:17) running on Duet 3 MB6HC v1.01 (SBC mode)
Board ID: 0JD2M-999AL-D25S4-7J1D2-3SJ6K-T51V3
Used output buffers: 1 of 40 (18 max)
=== RTOS ===
Static ram: 135136
Dynamic ram: 96472 of which 0 recycled
Never used RAM 68768, free system stack 198 words
Tasks: SBC(2,ready,0.8%,796) HEAT(3,nWait 6,0.0%,369) Move(4,nWait 6,0.0%,333) TMC(4,nWait 6,2.8%,353) CanReceiv(6,nWait 1,0.1%,794) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,353) MAIN(2,running,93.9%,440) IDLE(0,ready,2.4%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:00:37 ago, cause: software
Last software reset at 2024-09-18 18:45, reason: User, Expansion spinning, available RAM 65064, slot 0
Software reset code 0x6012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
MCU temperature: min 33.9, current 34.3, max 34.5
Supply voltage: min 22.7, current 23.5, max 23.6, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.1, max 12.1, under voltage events: 0
Heap OK, handles allocated/used 99/4, heap memory allocated/used/recyclable 2048/88/40, gc cycles 0
Events: 0 queued, 0 completed
Date/time: 2024-09-18 18:46:21
Slowest loop: 25.07ms; fastest: 0.07ms
=== Storage ===
Free file entries: 20
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 ===
Segments created 0, maxWait 0ms, bed comp in use: none, height map offset 0.000, hiccups added 0 (0.00/0.00ms), max steps late 0, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 0.00/0/0.00 0.00/0/0.00 0.00/0/0.00
next step interrupt due in 297 ticks, disabled
Driver 0: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0
Driver 1: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0
Driver 2: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0
Driver 3: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0
Driver 4: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0
Driver 5: standstill, SG min n/a, mspos 8, reads 8720, writes 11 timeouts 0
Phase step loop runtime (us): min=0, max=2, frequency (Hz): min=1913, max=2089
=== DDARing 0 ===
Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0]
=== DDARing 1 ===
Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0]
=== Heat ===
Bed heaters -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.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 0x80000003
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== Filament sensors ===
check 0 clear 0
Extruder 0 sensor: no filament
=== CAN ===
Messages queued 252, received 2403, lost 0, ignored 0, errs 315, boc 0
Longest wait 55ms for reply type 6041, peak Tx sync delay 50472, free buffers 50 (min 49), ts 187/186/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 1854/1854
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x2858c
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.5.2 (2024-06-12 07:09:26, 32-bit)
HTTP+Executed:
> Executing M122
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 60.06, max time between full transfers: 125.2ms, max pin wait times: 33.5ms/14.1ms
Codes per second: 2.94
Maximum length of RX/TX data transfers: 4476/1040

dc42

@MaxGyver is it repeatable? If so then please post your config.g file and the GCode file.

balajiramani

@dc42 I was wondering when we might a fix for this issue? I really like the quality of the prints with 3.6 and hence don't want to downgrade, but can't start a long print because of the step timing error.

dc42

@balajiramani I'll need to either find a reproducible test case, or add some debug to get more information when this fault occurs.

balajiramani

@dc42 Understand. Let me know if I can help in any way.

OwenD

I have just had the same error about 3 hours into a 5 hour print.

22/09/2024, 1:55:16 pm 	Error: Movement halted because a step timing error occurred (code 3). Please reset the controller.

Duet 2 WiFi 3.6.0-alpha.5+1

M122 after error

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.6.0-alpha.5+1 (2024-08-31 17:50:58) running on Duet WiFi 1.02 or later
Board ID: 08DGM-917NK-F2MS4-7J1DA-3S86T-TZTWD
Used output buffers: 7 of 26 (24 max)
=== RTOS ===
Static ram: 23360
Dynamic ram: 72224 of which 12 recycled
Never used RAM 8368, free system stack 106 words
Tasks: NETWORK(2,nWait 6,16.3%,202) ACCEL(6,nWait 5,0.0%,345) HEAT(3,nWait 5,0.1%,315) Move(4,invalid,3.3%,266) MAIN(1,running,79.8%,672) IDLE(0,ready,0.5%,29), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 05:49:08 ago, cause: software
Last software reset time unknown, reason: User, Gcodes spinning, available RAM 19896, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x08
Aux0 errors 0,2,0
MCU temperature: min 23.6, current 31.4, max 31.9
Supply voltage: min 1.1, current 24.3, max 24.6, under voltage events: 1, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/22, heap memory allocated/used/recyclable 2048/1704/1320, gc cycles 572
Events: 0 queued, 0 completed
Date/time: 2024-09-22 14:34:22
Slowest loop: 451.79ms; fastest: 0.13ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 8
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 10.1ms, write time 97.4ms, max retries 0
=== Move ===
Segments created 588, maxWait 153529ms, bed comp in use: mesh, height map offset 0.000, hiccups added 276 (8.29ms), max steps late 0, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 6390.00/6368/0.76 14761.00/14757/0.70 40648.00/40648/0.00
no step interrupt scheduled
Driver 0: standstill, SG min n/a
Driver 1: standstill, SG min 241
Driver 2: standstill, SG min 0
Driver 3: standstill, SG min 0
Driver 4: standstill, SG min 228
Driver 5: 
Driver 6: 
Driver 7: 
Driver 8: 
Driver 9: 
Driver 10: 
Driver 11: 
=== DDARing 0 ===
Scheduled moves 1473967, completed 1473965, LaErrors 0, Underruns [9, 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.3
Heater 1 is on, I-accum = 0.3
=== GCodes ===
Movement locks held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is doing "G1 X80.404 Y147.896 E.00085" 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
Daemon is doing "G4 S2" in state(s) 0 0, running macro
Autopause is idle in state(s) 0
Q0 segments left 1
Code queue 0 is empty
=== Filament sensors ===
check 79464683 clear 1287376
Extruder 0 sensor: ok
=== Network ===
Slowest loop: 117.01ms; fastest: 0.00ms
Responder states: 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 bc:dd:c2:89:a0:bb
Module reset reason: Power up, Vcc 3.38, flash size 4194304, free heap 38948
WiFi IP address 192.168.1.163
Signal strength -52dBm, channel 6, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 4 5 0 0 0 0 0 0

EDIT:
Of interest to anyone testing , I think I've saved the print by turning off the power and recovering from power failure.

Kiolia

I don't have a way to reproduce yet, but I'm seeing intermittent issues that may be related to machine uptime and/or changes to stepper current settings via M906. Several times now, I have seen a problem where a new print underextrudes severely after 1) running a print to completion and then 2) changing at least one stepper current with M906. There's no sound of step loss or evidence of grinding. As before, this is a 6HC with E on a 3HC as a mixing extruder with 2 steppers at ratios 100% each. I'm running a 0.5 CHT nozzle, but cold pulls after these incidents reveal no debris, and each time I've cold-pulled and restarted the machine, all was fine.

I wouldn't be reporting this yet, except that today, after the issue repeated, I discovered that I was able to easily hand-feed filament through the extruder while it was tensioned, which is normally only possible on startup before the extruder has been moved -- yet this was shortly after commanding retraction moves to unload the filament and trim the end, so the E steppers must have been at least engaged at idle (set to 25%). M122, M122 B1, and checking the current settings revealed nothing obvious, but the extruder acted like its steppers were unpowered or at least significantly under-currented. I'm pushing my machine hard right now, so it's always possible something else is going on, but I wanted to document this in case it's a thing with the alpha. Also worth noting that I had never clogged this hot end/nozzle before switching to the alpha.

EDIT: I had not yet switched off the machine, but after reloading the filament and just letting everything sit while I wrote this report, I tried hand-feeding the filament again and it is significantly harder -- more what I'd expect from the idle state.

Some specifics for the prints I ran this afternoon: I ran a speedbenchy print that finished in 3:36 with no extrusion issues, allowed about 10 minutes for board and stepper temps to steadystate, re-sliced with a change only to accels (100->120k), used M906 to change E current from 1800 to 2000 (a value I've run many times -- I was testing lower current), then ran the new gcode and got the result shown. To my eye this does not look like a clog -- it's too consistent.

gloomyandy

@Kiolia What version of RRF are you using?

Kiolia

@gloomyandy 3.6.0 5+1.

Kiolia

To follow up on the strange extrusion event, I re-ran the same print with the same config settings as before today, and extrusion appeared normal again -- so it wasn't the gcode's fault. Both prints layer shifted and were cancelled at about the same point, so out of curiosity I weighed them. The first one with the extrusion issue weighed 58% of the second one. I wondered if it would be a nice round number like half, but I guess not.