RepRapFirmware 3.6.0-alpha.4+3 available for testing

Exerqtor

@dc42 Awesome, i will install it and try the same testprint right away

balajiramani

@dc42 The delta calibration procedure works fine with 3.5.2. With 3.6.0-alpha*, I run into the issue. I checked the values of M665 and M666 in both 3.5.2 and 3.6.0-alpha and they are the same values.

Here is what I see with 3.5.2:

8/31/2024, 5:09:41 PM	M666
                        Endstop adjustments X-1.26 Y-1.03 Z2.30, tilt X0.00% Y0.00%
8/31/2024, 5:09:38 PM	M665
                        Diagonals 395.647:395.647:395.647, delta radius 214.803, homed height 359.884, bed radius 160.0, X -0.068°, Y -0.015°, Z 0.000°

Here is what I see with 3.6.0-alpha.4+3

8/31/2024, 5:58:57 PM	M666
                        Endstop adjustments X-1.26 Y-1.03 Z2.30, tilt X0.00% Y0.00%
8/31/2024, 5:58:56 PM	M665
                        Diagonals 395.647:395.647:395.647, delta radius 214.803, homed height 359.884, bed radius 160.0, X -0.068°, Y -0.015°, Z 0.000°

Adrian52

@balajiramani Hi - sorry for the delay
here is my bed.g. I have a 250mm dia round bed

; Auto calibration routine for large delta printer
M561                    ; clear any bed transform

; If the printer hasn't been homed, home it
;if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
  G28

; Probe the bed and do auto calibration
G1 X-70 Y-60 Z10 F6000        ; go to just above the first probe point
while true
  if iterations = 5
    abort "too many auto calibration attempts"
  G30 P0 X-70 Y-60 Z-99999
  if result != 0
    continue
  G30 P1 X-85 Y0 Z-99999
  if result != 0
    continue
  G30 P2 X-50 Y75 Z-99999
  if result != 0
    continue
  G30 P3 X0 Y85 Z-99999
  if result != 0
    continue
  G30 P4 X50 Y75 Z-99999
  if result != 0
    continue
  G30 P5 X85 Y0 Z-99999
  if result != 0
    continue
  G30 P6 X75 Y-50 Z-99999
  if result != 0
    continue
  G30 P7 X0 Y-85 Z-99999
  if result != 0
    continue
  G30 P8 X-40 Y-40 Z-99999
  if result != 0
    continue
  G30 P9 X-50 Y0 Z-99999
  if result != 0
    continue
  G30 P10 X-40 Y40 Z-99999
  if result != 0
    continue
  G30 P11 X0 Y50 Z-99999
  if result != 0
    continue
  G30 P12 X40 Y40.00 Z-99999
  if result != 0
    continue
  G30 P13 X50 Y0 Z-99999
  if result != 0
    continue
  G30 P14 X40 Y-40 Z-99999
  if result != 0
    continue
  G30 P15 X-4 Y-2 Z-99999
  if result != 0
    continue
  G30 P16 X4 Y-2 Z-99999
  if result != 0
    continue
  G30 P17 X0 Y4 Z-99999 S6
  if result != 0
    continue
 
  if move.calibration.final.deviation <= 0.03
    break
  echo "Repeating calibration because deviation is too high (" ^ move.calibration.final.deviation ^ "mm)"
; end loop
echo "Auto calibration successful, deviation", move.calibration.final.deviation ^ "mm"
G1 X0 Y0 Z150 F5000                ; get the head out of the way
M500
G28

dc42

I've put the 3.6.0-alpha.5 binaries at https://www.dropbox.com/scl/fo/u79134f365jdacqsm0km3/AKMSKB_Fz63WH4hqLkIphuQ?rlkey=bpa9lja4jylkpu9syjfp31rho&dl=0 and the release notes at https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-360-alpha5.

Adrian52

@dc42 I didnt check the exact time , but just under 40 min would be about right for me too.

curieos

@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.

Exerqtor

@dc42 said in RepRapFirmware 3.6.0-alpha.4+3 available for testing:

I've put the 3.6.0-alpha.5 binaries at https://www.dropbox.com/scl/fo/u79134f365jdacqsm0km3/AKMSKB_Fz63WH4hqLkIphuQ?rlkey=bpa9lja4jylkpu9syjfp31rho&dl=0 and the release notes at https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-360-alpha5.

Just ran the initial function test with alpha.5, and the "pause" after each probe move that I mentioned back in July is gone now. Which sure is nice

I've noticed that a bug from earlier (don't remember when) seem to have been reintroduced though, when i push the "bed leveling" button on PD i't don't display any of the messages nested in bed.g on the PD, only in DWC.

Running the same test print as earlier on alpha.5 now to see if finish without any step timing errors.

And I can also comfirm that it finished the same test print without any issues!

The PA changes is quite segnificant compared to alpha.2 as well. As can be seen in the test prints:
alt text

Pressure advance changing every 10mm in these increments:

0-10mm = PA: 0.045s.
10-20mm = PA: 0.025s.
20-30mm = PA. 0.01s.
30-40mm = PA: 0.0075s.
40-50mm = PA: 0.005s.
50-60mm = PA: 0s / off.

tas

@dc42 Testing 3.6.0-alpha.5 on my Duet2Wifi Ender 5 Plus using the same gcode that failed before. Also using DWC 3.6.0-alpha.2+1.

Just passed 40 minutes with no issues.

dc42

@curieos said in RepRapFirmware 3.6.0-alpha.4+3 available for testing:

@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.

Thanks. The bug could also occur at multiples of 47 (38 on Duet 2) minutes after the machine has been powered up or reset.

balajiramani

@Adrian52 Thank you for your copy of bed.g. The one big difference that I saws that the initial move in your file, after homing, is to move the head just above the probe point, where as in the version that I had, I was moving to X0 Y0. When I changed it to go just above the first point, so that the head is vertically above the first probe point, the bed calibration routine worked fine.

So, it looks like there seems to be a difference in the behavior depending on where the head is, relative to the first probe point and it is quite repetable for me. This seems to be a regression as compared to 3.5.2. At this point, I am glad that I found a way to get bed calibration working again on 3.6.0.

@dc42 can you check the behaviour on your end to see if you are able to reproduce this issue on the delta that you have?

Thanks,
Balaji

tas

@dc42
Duet2Wifi print completed after 1 hour 46 minutes without issues.
Thanks for the fix.

dc42

@balajiramani said in RepRapFirmware 3.6.0-alpha.4+3 available for testing:

@dc42 can you check the behaviour on your end to see if you are able to reproduce this issue on the delta that you have?

Thanks, I too had a move to just above the first probe point in my bed.g file, and if I use a move to X0 Y0 instead then I see the issue that you reported.

Adrian52

@dc42 a 1hr print completed for me too - thanks for the fix. Print quality looks very nice too.

dc42

@balajiramani I've fixed that in the new binaries at https://www.dropbox.com/scl/fo/u79134f365jdacqsm0km3/AKMSKB_Fz63WH4hqLkIphuQ?rlkey=bpa9lja4jylkpu9syjfp31rho&dl=0. The main build binaries are now version 3.6.0-alpha.5+1. Expansion board binaries are still 3.6.0-alpha.5.

Notepad

Just doing a simple test print and I noticed the extruder stopped pushing filament after 2 minutes.
After pause and cancelling the print, I manually started extruding some filament to see if it was a nozzle clog and I get the following error

Error: Push(): stack overflow on Aux
Error: Pop(): stack underflow on Aux

I have noticed a few times my PanelDue has seemed slightly unresponsive with delays between button presses and actions happening. This has also appeared during homing where the transition from HomeY.g to HomeZ.g has had a micro delay.

m122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.6.0-alpha.5 (2024-08-31 12:38:17) running on Duet 3 MB6HC v1.02 or 1.02a (SBC mode)
Board ID: 0JD4M-958L1-M2NS0-7JTDD-3S06P-1KHKX
Used output buffers: 1 of 40 (40 max)
=== RTOS ===
Static ram: 135136
Dynamic ram: 97412 of which 3300 recycled
Never used RAM 86680, free system stack 125 words
Tasks: SBC(2,ready,1.0%,809) HEAT(3,nWait 6,0.0%,325) Move(4,nWait 6,0.0%,221) TMC(4,nWait 6,2.9%,351) CanReceiv(6,nWait 1,0.0%,790) CanSender(5,nWait 7,0.0%,329) CanClock(7,delaying,0.0%,348) MAIN(2,running,95.9%,101) IDLE(0,ready,0.0%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 01:19:54 ago, cause: software
Last software reset at 2024-08-31 22:12, reason: User, Gcodes spinning, available RAM 92152, slot 0
Software reset code 0x6003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0043c000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x04
Aux0 errors 0,0,0
MCU temperature: min 37.0, current 38.3, max 38.4
Supply voltage: min 24.9, current 25.0, max 25.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.2, max 12.4, under voltage events: 0
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/116/116, gc cycles 0
Events: 1 queued, 1 completed
Date/time: 2024-08-31 23:32:12
Slowest loop: 77.45ms; fastest: 0.05ms
=== 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 257, maxWait 1753400ms, bed comp in use: mesh, 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: 16320.00/16320/0.00 0.00/0/-0.00 46359.00/46360/-1.00
next step interrupt due in 137 ticks, disabled
Driver 0: standstill, SG min 0, mspos 152, reads 19611, writes 49 timeouts 0
Driver 1: standstill, SG min n/a, mspos 8, reads 19649, writes 11 timeouts 0
Driver 2: standstill, SG min 0, mspos 136, reads 19611, writes 49 timeouts 0
Driver 3: standstill, SG min 0, mspos 696, reads 19579, writes 81 timeouts 0
Driver 4: standstill, SG min n/a, mspos 8, reads 19649, writes 11 timeouts 0
Driver 5: standstill, SG min 0, mspos 408, reads 19579, writes 81 timeouts 0
Phase step loop runtime (us): min=0, max=29, frequency (Hz): min=1139, max=8241
=== DDARing 0 ===
Scheduled moves 4187, completed 4187, 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 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters 2 -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 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 0x80000007
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 47342, received 96210, lost 0, ignored 0, errs 1, boc 0
Longest wait 1ms for reply type 6042, peak Tx sync delay 229, free buffers 50 (min 49), ts 23971/23970/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 57990/57990
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x284f0
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.5.2 (2024-06-12 07:12:47, 64-bit)
HTTP+Executed:
> Executing M122
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 39.48, max time between full transfers: 37.2ms, max pin wait times: 34.4ms/1.2ms
Codes per second: 0.85
Maximum length of RX/TX data transfers: 4436/1260

So far the test has been on 3.6.a5 next is to test a5+1

Edit:

A5+1 same extruder stopping behaviour, no pop/push error
Reverted to 3.5.2 and behaviour is identical. I think the roto extruder cannot push more than 30cubicmm/s with my current setup as it is stalling

As I am exceedingly fresh with SBC equipped duets, If there is a recommended process on how to update the SBC (pi5) instead of me dropping in the new 3.6.Ax .bin files, I would very much appreciate the advice.

Edit 2:

Something is up with my config.g or my roto as its stalling at relatively normal speeds regardless of firmware versions. The actually motor stalling is probably a red herring of a new machine (never used a roto before) but the Push/Pop error is definitely something out of the ordinary.

balajiramani

@dc42 Thank you! Verified that this version workes, irrespective of what the starting point for the bed calibration is.

o_lampe

@balajiramani Thanks for being so persistent, posting your calibration issues. It's a huge relieve for me, @dc42 found a solution.
I wondered if it was related to the, IHMO pretty huge endstop differences?

8/31/2024, 5:58:57 PM	M666
                        Endstop adjustments X-1.26 Y-1.03 Z2.30, tilt X0.00% Y0.00%

dc42

@Notepad I think the Push and Pop errors are happening because you are still running version 3.5.2 of Duet Control Server.

balajiramani

@o_lampe I think how @dc42 interacts with the community and listens to each one of us, is what makes the whole Duet ecosystem amazing!

While the endstop values are high, I don't think it is related to that. @dc42 what do you think?

Thanks,
Balaji

dc42

@balajiramani it wasn't relayed to the endstop adjustments. The code to segment automatically-generated moves didn't always work.