[3.6.0.Beta.2+4] G30 Z motion max accel not enforced

Notepad

It looks like something related to probing speeds might have broken in Beta2+4

The first homing process from a fresh restart works completely normally. but subsequent homing procedures appear to either have the wrong accelerations or max speed applied.
Sending G30 on its own seems to be completely fine and doesn't replicate the issue.

I have made a YouTube Video showing the behaviour by pressing the Quick Home macro x3 times from a cold boot
https://www.youtube.com/shorts/KTWl_apopfc

config.g
Quick Home XL.g

m122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.6.0-beta.2+4 (2024-12-01 18:12:13) running on Duet 3 MB6HC v1.02 or 1.02a (SBC mode)
Board ID: 0JD2M-9P9DA-F0PSD-6JKDD-3S06M-9PSH2
Used output buffers: 1 of 40 (17 max)
=== RTOS ===
Static ram: 136756
Dynamic ram: 98216 of which 2936 recycled
Never used RAM 90068, free system stack 117 words
Tasks: LASER(5,nWait 7,0.0%,223) SBC(2,ready,0.9%,825) HEAT(3,nWait 6,0.0%,323) Move(4,nWait 6,0.0%,236) TMC(4,nWait 6,3.1%,345) CanReceiv(6,nWait 1,0.0%,794) CanSender(5,nWait 7,0.0%,334) CanClock(7,delaying,0.0%,352) MAIN(2,running,95.5%,101) IDLE(0,ready,0.4%,29) USBD(3,blocked,0.0%,144), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:04:38 ago, cause: software
Last software reset at 2024-12-01 21:14, reason: User, Platform spinning, available RAM 90044, slot 1
Software reset code 0x2000 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0043c000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 39.4, current 39.8, max 40.0
Supply voltage: min 25.0, current 25.1, max 25.2, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.2, max 12.3, under voltage events: 0
Heap OK, handles allocated/used 99/10, heap memory allocated/used/recyclable 2048/164/24, gc cycles 0
Events: 0 queued, 0 completed
Date/time: 2024-12-01 21:19:15
Slowest loop: 55.75ms; fastest: 0.05ms
USB interrupts 3
=== 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 30, maxWait 94377ms, bed comp in use: none, height map offset 0.000, hiccups added 0/0 (0.00/0.00ms), max steps late 0, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 62400.00/62400/0.00 -11200.00/-11200/0.00 28000.00/28000/0.00
no step interrupt scheduled
Driver 0: standstill, SG min 0, mspos 392, reads 32681, writes 34 timeouts 0
Driver 1: standstill, SG min n/a, mspos 8, reads 32704, writes 11 timeouts 0
Driver 2: standstill, SG min 0, mspos 392, reads 32681, writes 34 timeouts 0
Driver 3: standstill, SG min 0, mspos 756, reads 32668, writes 47 timeouts 0
Driver 4: standstill, SG min n/a, mspos 8, reads 32704, writes 11 timeouts 0
Driver 5: standstill, SG min 0, mspos 1012, reads 32668, writes 47 timeouts 0
Phase step loop runtime (us): min=0, max=28, frequency (Hz): min=1677, max=2459
=== DDARing 0 ===
Scheduled moves 33, completed 33, 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 -1 -1 -1 -1, ordering errHeater 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 0, running macro
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
=== CAN ===
Messages queued 2512, received 5581, lost 0, ignored 0, errs 136, boc 0
Longest wait 1ms for reply type 6043, peak Tx sync delay 21742, free buffers 50 (min 49), ts 1394/1393/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 10792/10792
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x27d20
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.6.0-beta.2 (2024-11-14 11:02:38, 64-bit)
HTTP+Executed:
> Executing M122
Daemon:
>> Doing macro daemon.g, started by system
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 39.52, max time between full transfers: 53.8ms, max pin wait times: 52.8ms/2.3ms
Codes per second: 6.30
Maximum length of RX/TX data transfers: 4361/960

dc42

@Notepad thanks for providing the video. What was the last version you ran that did not have this issue?

PS - instead of reducing XY acceleration using M201 and then restoring it, you can use M201.1.

Notepad

@dc42 THe last version I was running was Beta2+1
At the time I wasnt aware of a +2 +3 or available. If you have the Drop box link, I can load each one up and see which version started the behaviour

dc42

@Notepad thanks. Beta 2+3 is at https://www.dropbox.com/scl/fo/pasag1g18orahwvn49qp2/ABWgw6D-TyKWxxurTmGwiUE?rlkey=r9h3rjyw1l4wh7xbr8yho37gw&dl=0 however it has an issue with CoreXY kinematics that cause the first X or Y movement to be diagonal. You should be able to work around that by commanding very short X and Y movement before homing. I didn't publisg the beta2+2 builds.

Please can you also try the following with beta2+4:

After homing for the first time, send M201, M203 and M906 to check that the Z acceleration, speed and motor current are as expected.
Try removing the two M201 commands from QuickHomeXL.g and use M201.1 instead to set lower acceleration when homing.
If it is safe to do so, try removing the two M906 commands from Quick HomeXL.g.

These tests may tell us whether the problem really is that Z acceleration or speed is too high, or motor current is too low.

Notepad

@dc42
Will do. I had to step out the factory for today so I will get these tested tomorrow.

Notepad

@dc42 Just to keep you updated. I will have the testing results tomorrow

dc42

@Notepad we've found a more general issue with beta4 performing moves at incorrect speeds and I am working on a fix. Although the symptoms we have reproduced are different from yours, I suspect it is the same fault.

Notepad

@dc42 Thats good to know. is there any additional testing you would like me to undertake with this new identified behaviour?

Notepad

@dc42 Is it possible to get a binary made for the duet 2. last thing I need to test is if its hardware specific.

Notepad

@dc42

I have results so far!

For firmware updates with no gcode changes
Beta 2+1 behaves as expected
Beta 2+3 Produces the artefact (does not move in a diagonal at first move command)
Beta 2+4 Produces the artefact

Using Beta 2+4 the Quick Home XL macro has been edited with debug steps
Quick Home XL.txt

Which has produced the following

Whilst the order of the debug outputs are out of sync with the requests. once the values have been shifted around, the requested changes do appear to be happening.
This does not rule out if the printer is processing command moves with incorrect values, but it is more likely that the print to DWC service might have a delay.
Both behaviours however do not explain the sudden rise in the Z accelerations.

Replacing M201 in the macro with M201.1 in the config.g

Important to note the M201 in the macro only commands the X & Y motors, the Z acceleration is commanded in the config.g already (set to z500).

the Config.g was updated to include M201.1 Z300

This did no change to the behaviour

M906 was removed from the macro, which did noticeably increase the distance the bed could move before stalling. This definitely highlighted that the bed was accelerating very aggressively.

To guarantee that this behaviour is repeatable, I have tested this on a separate machine. This machine does not have a roto toolboard, and is instead using a D3-mini WITHOUT sbc.
The firmware version is 3.6.0.beta2+4
config.g Quick Home XL.txt

The behaviour of the motor stalling from excessive accelerations is also present on this machine.

This currently concludes my available testing. It appears that the use of M201, M201.1 M906 do not affect the behaviour of the printers, and the z motion on consecutive homing moves appears to stay broken.

Homing the printer through the homeall button does appear to be working, The first use after using the macro does produce the same error, but subsequent uses of the homeall.g appears to be working normally.
The single error appeared when a G30 line was used in the middle of the homing sequence

What is very interesting is after using a mixture of homeall.g and quickhome.g the printer does not seem to be doing the incorrect behaviour any more. What did show up a single time before this behaviour change (but after the machine has been moving multiple times) is the print head on a homeY.g move, moved backwards in a 15 degree angle. After this the z movement stayed consistantly working normally.

My current gut feeling is the issue may be directly linked to the diagonal moving identified in Beta2+3

I hope this is helpful @dc42, if there is any way to gather more advanced debug logs that would be helpful. feel free to use me in any way needed,