Unable to obtain 'trsync_state' response - reproducible case

I’ve been struggling with this intermittent fatal error message over the last week or so and tonight it seems to have become perfectly reproducible (which I suppose is a good thing long-term, but a bad thing short-term).

I have a SKTank kit (CoreXY with 3 Z stepper motors) on a BTT Octopus board (v1.0) with a Raspberry Pi 3B. Endstops are optical on X, Y, and Z (only the first Z). Probe is an inductive PNP NO, fed by 12V. All of that appears (to me) to be working just fine. X/Y (A/B?) motors are full-size Nema 17. Zs are miniature, gearbox steppers. All 6 driver boards started out as TMC2225s, changed late tonight to TMC2209s as a troubleshooting measure.

When I power the printer up, home all axes, then do a Z Tilt adjust, it will run through the entire first pass of the Z-tilt just fine (7 points), tilt adjust the bed, then on the second pass, it will die as soon as the inductive probe lights on the 5th point. (“As soon as” is per human perception, not detailed timing analysis.)

This repeated 5 times in a row on HEAD of master (f2b4d353d859e0fc75a13b53050812516b06302c).

Things I’ve tried:

  • Two different RPi3Bs.
  • Three different power supplies (from Octopus, Amazon FireTV 9W #1, Amazon FireTV 9W #2). The first two measured 4.93V on the input, 5.02V on the input, and 5.15V on the input. The first two gave vcgencmd get_throttled throttled=0x50005; the last one is always 0x0 (before and after failures).
  • Changing the 5 stepper drivers from TMC2225 (using 2208 config) to TMC2209 boards (and 2209 config)
  • Commits 07004a889d9664eefd65613d79c663d3ca705c20, 983951443cf14fe2985585c2c2eb20efe526411d, b6d8cf27d25faecfa47404924a757dc09e7a84a3, and bf5c2505abc27c5dc57dd663060e0a756b6391bb (last one I couldn’t get to connect over USB, so I skipped it and went back to HEAD).

Attache are two klippy logs and one moonraker log. (I failed, via a mistake, to save the first one that did show an undervolt throttling on the previous power supply.)

The first klippy log shows a lot of experimentation over multiple commits and configurations.
The second klippy log and moonraker log is a simple reboot, followed by a reproduction of the error.

I’m a Klipper newb (running it successfully on another Ender 3), but I’ve got a lot of motivation to get my printer working and I appear to have a reproducible case (at least at the moment) that might be helpful if anyone has further troubleshooting strategies. I don’t “know python” but I was a full-time software engineer in C/C++/C# so I’m not totally hopeless.

Thanks a bunch for any tips or suggestions!
klippy.log.reproducible-Z-tilt-trsync-error.log (2.3 MB)

(New users can only put two links in a post, so second logs coming in a reply.)

klippy.log.reproducible-Z-tilt-trsync-error-2.log (172.1 KB)
moonraker.log.reproducible-Z-tilt-trsync-error-2.log (31.3 KB)

It makes sense to concentrate on one topic: See Unable to obtain 'trsync_state' response - #4 by LordTimmeh

I’m happy to move my traffic and testing over to that thread. Done.

I had looked at that thread, saw it had been idle 3 days, and thought that combined with having what seems like a reproducible case was enough to make a new thread, but I admit I was waffling on the “do I ‘stomp’ on the other thread or start a new one?”

maybe octopus not suitable for corexy3z,i have 3z machine and octopus too.It will became more and more skewed when change step https://klipper.discourse.group/t/each-layer-will-becoming-more-and-more-skewed/581/5.